Dlaczego UML?<\/h2>\n
Wraz z rosn\u0105c\u0105 rozmiarem i z\u0142o\u017cono\u015bci\u0105 architektur oprogramowania ro\u015bnie potrzeba modeli oprogramowania. UML to dominuj\u0105cy j\u0119zyk modelowania w bran\u017cy oprogramowania. Obecnie jest to standard de facto przyj\u0119ty przez Object Management Group, najwi\u0119ksz\u0105 konsorcjum oprogramowania na \u015bwiecie. Trudno znale\u017a\u0107 projekt oprogramowania z wi\u0119cej ni\u017c 10 programistami, kt\u00f3ry nie wykorzystuje UML w jakikolwiek spos\u00f3b do okre\u015blenia swojej architektury.<\/p>\n
Oto kilka dodatkowych fakt\u00f3w dotycz\u0105cych wykorzystania UML w naszym procesie rozwoju oprogramowania:<\/p>\n
- \n
- Oprogramowanie staje si\u0119 coraz bardziej z\u0142o\u017cone: do\u015b\u0107 stara wersja Windows XP > 40 milion\u00f3w linii kodu.<\/li>\n
- Jeden programista nie mo\u017ce zarz\u0105dza\u0107 ca\u0142\u0105 t\u0105 ilo\u015bci\u0105 kodu.<\/li>\n
- Kod nie jest \u0142atwo zrozumia\u0142y dla programist\u00f3w, kt\u00f3rzy go nie pisali.<\/li>\n
- Potrzebujemy prostszych reprezentacji dla z\u0142o\u017conych system\u00f3w: modelowanie to spos\u00f3b radzenia sobie z z\u0142o\u017cono\u015bci\u0105.<\/li>\n<\/ul>\n
Co to jest model?<\/h2>\n
- \n
- Model to abstrakcja rzeczywisto\u015bci, pomijaj\u0105ca szczeg\u00f3\u0142y.<\/li>\n
- \u201eZbi\u00f3r wszystkich element\u00f3w opisuj\u0105cych Tw\u00f3j system, wraz z ich po\u0142\u0105czeniami, tworzy Tw\u00f3j model.\u201d (Russ i Hamilton 12).<\/li>\n<\/ul>\n
kiedy u\u017cywamy UML do tworzenia modeli systemu przed jego kodowaniem, reprezentuj\u0105 one problem w uproszczony spos\u00f3b. Daj\u0105 struktur\u0119 do rozwi\u0105zywania problem\u00f3w. Pomagaj\u0105 zrozumie\u0107, jak mo\u017cna post\u0119powa\u0107 wobec danego problemu. Pozwalaj\u0105 r\u00f3wnie\u017c eksperymentowa\u0107 z wieloma rozwi\u0105zaniami. Poniewa\u017c modele tworzone s\u0105 przed rzeczywistym rozwojem systemu, mo\u017cemy zrozumie\u0107 r\u00f3\u017cne mo\u017cliwo\u015bci, problemy, opcje itd. To r\u00f3wnie\u017c prowadzi do obni\u017cenia koszt\u00f3w rozwoju. Poniewa\u017c czas nie b\u0119dzie tracony na pr\u00f3by i b\u0142\u0119dy, produkt b\u0119dzie gotowy w kr\u00f3tszym czasie. Modele r\u00f3wnie\u017c pomagaj\u0105 zarz\u0105dza\u0107 z\u0142o\u017cono\u015bci\u0105 problemu, dzi\u0119ki czemu planowanie rozwoju, alokacja zasob\u00f3w takich jak maszyny, programi\u015bci, testerzy mo\u017ce by\u0107 \u0142atwo przeprowadzona.<\/p>\n
Czym UML NIE JEST?<\/h2>\n
- \n
- UML to nie notacja, ale j\u0119zyk.<\/li>\n
- UML nie nale\u017cy do nikogo. Jest otwarte do u\u017cytku przez ka\u017cdego, kto chce go wykorzysta\u0107. Nie jest w\u0142asno\u015bci\u0105 prywatn\u0105.<\/li>\n
- UML to nie proces ani metoda.<\/li>\n
- UML zach\u0119ca do stosowania technik zorientowanych obiektowo oraz iteracyjnych cykli rozwoju oprogramowania.<\/li>\n
- UML nie jest trudny. Jest du\u017cy, ale nie trzeba go zna\u0107 w ca\u0142o\u015bci. Nie ma r\u00f3wnie\u017c potrzeby u\u017cywa\u0107 lub rozumie\u0107 ka\u017cdej drobnej rzeczy w nim.<\/li>\n
- UML nie jest czasoch\u0142onny. Je\u015bli u\u017cywany odpowiednio, stosowanie UML zmniejsza koszty rozwoju. W tym samym czasie daje zalety \u0142atwego zrozumienia i komunikacji, zwi\u0119kszonej produktywno\u015bci i lepszej jako\u015bci.<\/li>\n
- UML nie jest ograniczony. Jest wystarczaj\u0105co elastyczny, aby umo\u017cliwi\u0107 now\u0105 leksyk\u0119 (koncepcje, s\u0142owa i terminy), w\u0142a\u015bciwo\u015bci (dodatkowe informacje o s\u0142owach) i semantyk\u0119 (zasady j\u0119zyka), kt\u00f3re s\u0105 wymagane w konkretnym dziedzinie.<\/li>\n<\/ul>\n
Cel UML<\/h2>\n
- \n
- J\u0119zyk modelowania wizualnego, a nie j\u0119zyk programowania wizualnego. Cho\u0107 niekt\u00f3re narz\u0119dzia modelowania maj\u0105 generatory kodu i niekt\u00f3re mog\u0105 odwzorowywa\u0107 modele z kodu.<\/li>\n
- Zosta\u0142 zaprojektowany w celu tworzenia diagram\u00f3w wspieraj\u0105cych proces rozwoju oprogramowania, jednak UML to nie jest proces ani metoda rozwoju oprogramowania. Dlatego UML jest niezale\u017cny od procesu.<\/li>\n
- Standardowy j\u0119zyk do tworzenia szkic\u00f3w oprogramowania.<\/li>\n
- Narz\u0119dzie komunikacji.<\/li>\n
- J\u0119zyk do dokumentowania wymaga\u0144, architektury, test\u00f3w, planowania projektu itp\u2026<\/li>\n
- Przeznaczony jest do system\u00f3w oprogramowania, ale mo\u017ce modelowa\u0107 inne systemy.<\/li>\n
- Przeznaczony jest do wspierania procesu rozwoju opartego na obiektach.<\/li>\n
- Mo\u017ce uchwyci\u0107 zar\u00f3wno struktury statyczne, jak i zachowanie dynamiczne systemu.<\/li>\n
- Diagramy UML mog\u0105 pom\u00f3c zaanga\u017cowanym stronom zrozumie\u0107, om\u00f3wi\u0107 i zgodzi\u0107 si\u0119 na wymagania.<\/li>\n
- Diagramy UML mog\u0105 pom\u00f3c w abstrakcyjnym przedstawieniu skomplikowanych proces\u00f3w na poziomie \u0142atwiejszym do zrozumienia.<\/li>\n
- Diagramy UML pomagaj\u0105 u\u0142atwi\u0107 rozwi\u0105zywanie problem\u00f3w.<\/li>\n<\/ul>\n
Co oferuje j\u0119zyk modelowania?<\/h2>\n
- \n
- Elementy modelu<\/i><\/b>: Poj\u0119cia i semantyka<\/li>\n
- Notacja<\/i><\/b>: Wizualne przedstawienie element\u00f3w modelu<\/li>\n
- Wskaz\u00f3wki<\/i><\/b>: Wskaz\u00f3wki i sugestie dotycz\u0105ce u\u017cywania element\u00f3w w notacji<\/li>\n<\/ul>\n
Kr\u00f3tka historia<\/h2>\n
W latach 80., gdy zacz\u0119li\u015bmy modelowanie, istnia\u0142o wiele r\u00f3\u017cnych metodologii. Ka\u017cda z metodologii mia\u0142a swoj\u0105 w\u0142asn\u0105 notacj\u0119. Problem polega\u0142 na tym, \u017ce je\u015bli r\u00f3\u017cni ludzie u\u017cywali r\u00f3\u017cnych notacji, w pewnym momencie kto\u015b musia\u0142 dokona\u0107 t\u0142umaczenia. Cz\u0119sto jeden symbol oznacza\u0142 jedno w jednej notacji, a zupe\u0142nie co\u015b innego w innej notacji. W 1991 roku wszyscy zacz\u0119li publikowa\u0107 ksi\u0105\u017cki. Grady Booch wyda\u0142 swoj\u0105 pierwsz\u0105 edycj\u0119. Ivar Jacobson wyda\u0142 swoj\u0105, a Jim Rumbaugh swoj\u0105 metodologi\u0119 OMT. Ka\u017cda ksi\u0105\u017cka mia\u0142a swoje zalety i wady. OMT by\u0142 bardzo silny w analizie, ale s\u0142abszy w projektowaniu. Metodologia Boocha by\u0142a silniejsza w projektowaniu, ale s\u0142absza w analizie. A Objectory Ivara Jacobsona \u015bwietnie radzi\u0142 sobie z do\u015bwiadczeniem u\u017cytkownika, kt\u00f3rego ani Booch, ani OMT nie brali naprawd\u0119 pod uwag\u0119 w tamtym czasie. Booch i Jacobson po\u0142\u0105czyli swoje metody w 1994 roku, a potem w 1995 roku do\u0142\u0105czy\u0142 do nich Rumbaugh. W 1997 roku OMG wyda\u0142o UML 1.1, uwzgl\u0119dniaj\u0105c wk\u0142ad innych, np. Yourdena. Wersja UML v2.x to najnowsza wersja.<\/p>\n
Daty wydania<\/h3>\n
- \n
- 1995 \u2013 UML 0.8<\/li>\n
- 1996 \u2013 UML 0.9 \u2013 Trzej przyjaciele<\/li>\n
- 1997 \u2013 OMG przejmuje.<\/li>\n
- 1997 \u2013 OMG UML 1.1<\/li>\n
- 1998 \u2013 OMG UML 1.2<\/li>\n
- 1999 \u2013 OMG UML 1.3<\/li>\n
- 2001 \u2013 OMG UML 1.4<\/li>\n
- 2003 \u2013 OMG UML 1.5<\/li>\n
- 2003 \u2013 OMG UML 2.0 \u2013 U\u017cywane<\/li>\n
- 2005 \u2013 OMG UML 2.0 \u2013 Ostateczna<\/li>\n
- 2006 \u2013 OMG UML 2.1<\/li>\n
- UML2.1.2<\/b> (11\/04\/07) \u2013 Aktualna wersja od 27\/05\/08<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/What-is-UML.png\")
<\/a><\/p>\nMotywacja unifikacji metod przez \u201etrzech Amegos\u201d<\/h2>\n
- \n
- Fakt, \u017ce metody indywidualne ewoluowa\u0142y do siebie niezale\u017cnie<\/li>\n
- Unifikacja semantyki i notacji w celu zapewnienia stabilno\u015bci rynku projektowania obiektowego<\/li>\n
- Oczekiwanie, \u017ce unifikacja poprawi wcze\u015bniejsze metody indywidualne<\/li>\n<\/ul>\n
Partnerzy UML<\/h3>\n
\n
- \n
- Firma Rational Software Corporation<\/li>\n
- IBM<\/li>\n
- Hewlett-Packard<\/li>\n
- I-Logix<\/li>\n
- ICON Computing<\/li>\n
- Intellicorp<\/li>\n
- MCI Systemhouse<\/li>\n
- Microsoft<\/li>\n
- ObjecTime<\/li>\n
- Oracle<\/li>\n
- Platinum Technology<\/li>\n
- Taskon<\/li>\n
- Texas Instruments\/Sterling Software<\/li>\n
- Unisys<\/li>\n<\/ul>\n<\/blockquote>\n
Wprowadzenie notacji UML dla r\u00f3\u017cnych metod przed unifikacj\u0105<\/h2>\n
UML reprezentuje unifikacj\u0119 notacji Booch, OMT i Objectory, a tak\u017ce najlepsze pomys\u0142y licznych innych metodolog\u00f3w, jak pokazano na rysunku poni\u017cej. Poprzez unifikacj\u0119 notacji u\u017cywanych przez te metody obiektowe, j\u0119zyk modelowania unifikowany zapewnia podstaw\u0119 dla de facto standardu w dziedzinie analizy i projektowania obiektowego opartego na szerokim do\u015bwiadczeniu u\u017cytkownik\u00f3w.<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/UML-Imnput.png\")
<\/a><\/p>\n<\/h3>\n
Rola notacji<\/h2>\n
Notacja odgrywa wa\u017cn\u0105 rol\u0119 w ka\u017cdym modelu \u2013 jest klejem, kt\u00f3ry \u0142\u0105czy proces. Notacja ma trzy role:<\/p>\n
- \n
- S\u0142u\u017cy jako j\u0119zyk komunikacji decyzji, kt\u00f3re nie s\u0105 oczywiste lub nie mog\u0105 zosta\u0107 wyprowadzone z samego kodu.<\/li>\n
- Zapewnia semantyk\u0119 wystarczaj\u0105co bogat\u0105, aby uchwyci\u0107 wszystkie istotne decyzje strategiczne i taktyczne.<\/li>\n
- Oferuje form\u0119 wystarczaj\u0105co konkretn\u0105, aby ludzie mogli rozumowa\u0107, a narz\u0119dzia mog\u0142y j\u0105 przetwarza\u0107.<\/li>\n<\/ul>\n
J\u0119zyk modelowania unifikowanego (UML) zapewnia bardzo solidn\u0105 notacj\u0119, kt\u00f3ra rozwija si\u0119 od analizy do projektowania. Niekt\u00f3re elementy notacji (na przyk\u0142ad klasy, zwi\u0105zki, agregacje, dziedziczenie) wprowadzane s\u0105 w trakcie analizy. Inne elementy notacji (na przyk\u0142ad wska\u017aniki implementacji zawarto\u015bci i w\u0142a\u015bciwo\u015bci) wprowadzane s\u0105 w trakcie projektowania.<\/p>\n
Zalety UML<\/b><\/h2>\n
UML mo\u017cna stosowa\u0107 do r\u00f3\u017cnorodnychdziedziny zastosowa\u0144<\/strong>\u00a0(np. bankowo\u015b\u0107, finanse, internet, lotnictwo, medycyna, itd.) Mo\u017ce by\u0107 stosowane z wszystkimi g\u0142\u00f3wnymi obiektami i komponentami\u00a0metody rozwoju oprogramowania<\/strong>\u00a0i do r\u00f3\u017cnych\u00a0platform implementacyjnych.<\/strong><\/p>\n
- \n
- Wiesz dok\u0142adnie, co otrzymujesz<\/li>\n
- Zmniejszysz koszty rozwoju<\/li>\n
- Twoje oprogramowanie b\u0119dzie dzia\u0142a\u0107 tak, jak si\u0119 tego spodziewasz. Mniej nieprzyjemnych zaskocze\u0144<\/li>\n
- Poprawne decyzje s\u0105 podejmowane przed otrzymaniem s\u0142abo napisanego kodu. Zmniejszone koszty og\u00f3lne<\/li>\n
- Mo\u017cemy tworzy\u0107 bardziej wydajne pod wzgl\u0119dem pami\u0119ci i procesora systemy<\/li>\n
- Koszty utrzymania systemu b\u0119d\u0105 ni\u017csze. Mniej ponownego nauki\u00a0zajdzie<\/li>\n
- Praca z nowym programist\u0105 b\u0119dzie \u0142atwiejsza.<\/li>\n
- Komunikacja z programistami i zewn\u0119trznych kontrahent\u00f3w b\u0119dzie bardziej efektywna.<\/li>\n<\/ul>\n
Widoki UML 4 + 1<\/h2>\n
UML sk\u0142ada si\u0119 z nast\u0119puj\u0105cych czterech widok\u00f3w systemu w trakcie rozwoju (patrz rys. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:<\/p>\n
- \n
- Widok przypadk\u00f3w u\u017cycia:<\/em> pokazuje funkcjonalno\u015b\u0107 systemu z perspektywy zewn\u0119trznych aktor\u00f3w; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w przypadk\u00f3w u\u017cycia i czasem diagram\u00f3w dzia\u0142ania.<\/li>\n
- Widok logiczny: <\/em>pokazuje, jak ta funkcjonalno\u015b\u0107 jest zaprojektowana wewn\u0105trz systemu, pod k\u0105tem jego struktury statycznej i zachowania dynamicznego; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w klas i obiekt\u00f3w (model statyczny) oraz diagram\u00f3w przej\u015b\u0107 stan\u00f3w, sekwencji, wsp\u00f3\u0142pracy i dzia\u0142ania (model dynamiczny)<\/li>\n
- Widok komponent\u00f3w:<\/em> pokazuje organizacj\u0119 komponent\u00f3w oprogramowania; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w komponent\u00f3w.<\/li>\n
- Widok wdro\u017cenia:<\/em> pokazuje konfiguracj\u0119 fizyczn\u0105 (wdro\u017cenie) w\u0119z\u0142\u00f3w przetwarzania w czasie dzia\u0142ania w komputerach i urz\u0105dzeniach oraz komponent\u00f3w, proces\u00f3w i obiekt\u00f3w, kt\u00f3re na nich istniej\u0105; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w wdro\u017cenia.<\/li>\n
- Widok procesu:<\/em> pokazuje aspekt wsp\u00f3\u0142bie\u017cny systemu w czasie dzia\u0142ania, takie jak zadania, w\u0105tki, procesy i interakcje oraz rozwi\u0105zuje problemy zwi\u0105zane z komunikacj\u0105 i synchronizacj\u0105 tych w\u0105tk\u00f3w; opisuje si\u0119 je za pomoc\u0105 diagram\u00f3w dynamicznych (diagramy przej\u015b\u0107 stan\u00f3w, sekwencji, wsp\u00f3\u0142pracy i dzia\u0142ania) oraz diagram\u00f3w implementacji (diagramy komponent\u00f3w i wdro\u017cenia).<\/li>\n<\/ul>\n
![\"4+1](\"https:\/\/www.ibm.com\/developerworks\/rational\/library\/05\/0816_Louis\/figure-2.gif\"\/)
<\/p>\nKa\u017cdy system sk\u0142ada si\u0119 z statycznego<\/em> i dynamicznego<\/em> modelu. Model statyczny jest przedstawiany w diagramach klas i obiekt\u00f3w. Jednak\u017ce ujawnia niewiele w kontek\u015bcie zachowania systemu. Zachowanie systemu jest uchwycone graficznie za pomoc\u0105 scenariuszy (tj. diagram\u00f3w przypadk\u00f3w u\u017cycia), diagram\u00f3w sekwencji, diagram\u00f3w przej\u015b\u0107 stan\u00f3w i diagram\u00f3w dzia\u0142ania. Te stanowi\u0105 model dynamiczny systemu. Zachowanie systemu to \u0142\u0105czne zachowanie wszystkich obiekt\u00f3w nale\u017c\u0105cych do systemu.<\/p>\n
Je\u015bli chcemy odwzorowa\u0107 powy\u017csze pi\u0119\u0107 widok\u00f3w na iteracyjne fazy cyklu \u017cycia przedstawione na rys. 3, mogliby\u015bmy powiedzie\u0107 nast\u0119puj\u0105ce:<\/p>\n
- \n
- Analiza obiektowa (OOA), kt\u00f3ra tworzy model wymaga\u0144 u\u017cytkownik\u00f3w z perspektywy u\u017cytkownika, odwzorowuje si\u0119 na widok przypadk\u00f3w u\u017cycia.<\/li>\n
- Projektowanie obiektowe (OOD) dodaje szczeg\u00f3\u0142y i decyzje projektowe (z perspektywy programisty) do analizy i odwzorowuje si\u0119 na widok logiki.<\/li>\n
- Na ko\u0144cu implementacja lub programowanie obiektowe (OOP) odwzorowuje si\u0119 na widok procesu, wdro\u017cenia i komponentu.<\/li>\n<\/ul>\n
Diagramy UML 2<\/b><\/h2>\n
UML ma kilka r\u00f3\u017cnych typ\u00f3w diagram\u00f3w, kt\u00f3re mog\u0105 by\u0107 u\u017cywane do opisu modelu z r\u00f3\u017cnych punkt\u00f3w widzenia. Istniej\u0105 dwa g\u0142\u00f3wne kategorie diagram\u00f3w, kt\u00f3re nast\u0119pnie s\u0105 podzielone na podkategorie:<\/p>\n
- \n
- Diagramy strukturalne \u2013diagramy strukturalne<\/i>reprezentuj\u0105 aspekt statyczny systemu. Te aspekty statyczne reprezentuj\u0105 te cz\u0119\u015bci diagramu, kt\u00f3re tworz\u0105 g\u0142\u00f3wn\u0105 struktur\u0119 i dlatego s\u0105 stabilne. Te cz\u0119\u015bci statyczne s\u0105 reprezentowane przez klasy, interfejsy, obiekty, komponenty i w\u0119z\u0142y.<\/li>\n
- Diagramy zachowaniowe \u2013 ka\u017cdy system mo\u017ce mie\u0107 dwa aspekty: statyczny i dynamiczny. Dlatego model uznaje si\u0119 za kompletny, gdy oba aspekty s\u0105 w pe\u0142ni uwzgl\u0119dnione.\n
Diagramy zachowaniowe w zasadzie zapisuj\u0105 aspekt dynamiczny systemu. Aspekt dynamiczny mo\u017cna dalej opisa\u0107 jako zmieniaj\u0105ce si\u0119\/ruszaj\u0105ce cz\u0119\u015bci systemu.<\/div>\n<\/li>\n<\/ul>\n![\"UML](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2022\/02\/02-uml-diagram-types.png\"\/)
<\/p>\nDiagramy strukturalne<\/h2>\n
diagramy strukturalne<\/i>reprezentuj\u0105 aspekt statyczny systemu. Te aspekty statyczne reprezentuj\u0105 te cz\u0119\u015bci diagramu, kt\u00f3re tworz\u0105 g\u0142\u00f3wn\u0105 struktur\u0119 i dlatego s\u0105 stabilne.<\/div>\nTe cz\u0119\u015bci statyczne s\u0105 reprezentowane przez klasy, interfejsy, obiekty, komponenty i w\u0119z\u0142y. Cztery diagramy strukturalne to:<\/div>\n- \n
- Diagram klas<\/b>\u2013 diagram statycznej struktury klas i interfejs\u00f3w systemu oraz ich relacji lub powi\u0105za\u0144 (w tym dziedziczenia, agregacji i powi\u0105za\u0144), w tym operacji i atrybut\u00f3w klas. Tryby prezentacji to: powi\u0105zanie, dziedziczenie, zale\u017cno\u015b\u0107. Jest to bardzo powszechny diagram w UML.<\/li>\n
- Diagram obiekt\u00f3w<\/b>\u2013 to diagram statycznej struktury systemu w konkretnym momencie lub sytuacji (zdj\u0119cie), ilustruj\u0105cy relacj\u0119 w systemie.<\/li>\n
- Diagram komponent\u00f3w<\/b>\u2013 to diagram opisuj\u0105cy organizacj\u0119 i zale\u017cno\u015bci komponent\u00f3w wewn\u0105trz systemu.<\/li>\n
- Diagram struktury z\u0142o\u017conej<\/b>\u2013 to diagram badaj\u0105cy instancje czasu wykonania po\u0142\u0105czonych ze sob\u0105 instancji wsp\u00f3\u0142dzia\u0142aj\u0105cych poprzez po\u0142\u0105czenia komunikacyjne.<\/li>\n
- Diagram pakiet\u00f3w<\/b>\u2013 to diagram ilustruj\u0105cy, jak system jest podzielony na grupy logiczne i jakie mog\u0105 istnie\u0107 zale\u017cno\u015bci mi\u0119dzy tymi grupami.<\/li>\n
- Diagram wdro\u017cenia<\/b>\u2013 to diagram opisuj\u0105cy, jak jednostki fizyczne rozdzielalne (rozdzielalne elementy oprogramowania, aplikacje, serwery, aplikacje, sprz\u0119t itp.) tworz\u0105 architektur\u0119 systemu rozproszonego.<\/li>\n<\/ul>\n
Diagramy zachowaniowe<\/b><\/h2>\n
- \n
- Diagram przypadk\u00f3w u\u017cycia<\/b> \u2013 diagram przypadk\u00f3w u\u017cycia (funkcje\/serwisy oprogramowania) i rola aktor\u00f3w (u\u017cytkownicy \u2013 zar\u00f3wno ludzie, jak i systemy). Ten diagram jest z perspektywy u\u017cytkownika.<\/li>\n
- Diagram aktywno\u015bci<\/b> \u2013 to diagram dynamiki systemu poprzez modelowanie przep\u0142ywu sterowania od aktywno\u015bci do aktywno\u015bci. Pokazuje, jak system (np. obiekt\/klasa) reaguje na zdarzenie wewn\u0119trzne. (Uwaga: zdarzenia zewn\u0119trzne opisuje diagram stanu). W modelowaniu proces\u00f3w biznesowych mo\u017cesz u\u017cy\u0107 tego diagramu do przedstawienia logiki przypadku u\u017cycia lub regu\u0142y biznesowej.<\/li>\n
- Diagram stanu<\/b> (inaczej diagram stan\u00f3w, diagram maszyny stan\u00f3w) \u2013 to diagram, kt\u00f3ry pokazuje, jak system (np. obiekt\/klasa) reaguje na zdarzenie zewn\u0119trzne. (Uwaga: zdarzenia wewn\u0119trzne opisuje diagram aktywno\u015bci).<\/li>\n<\/ul>\n
Diagramy typ\u00f3w interakcji<\/b>\u2013 interakcje cz\u0119\u015bci organizacyjnych modelu.<\/p>\n
- \n
- Diagram sekwencji<\/b> \u2013 to diagram interakcji i przep\u0142ywu komunikat\u00f3w mi\u0119dzy obiektami oraz ich wzgl\u0119dnej kolejno\u015bci czasowej<\/li>\n
- Diagram komunikacji<\/b>(inaczej <\/b>Diagramy wsp\u00f3\u0142pracy UML1) \u2013 to diagram, kt\u00f3ry pokazuje, jak systemy wsp\u00f3\u0142pracuj\u0105 ze sob\u0105 w celu wykonania zadania oraz relacje, kt\u00f3re musz\u0105 istnie\u0107 mi\u0119dzy nimi. Diagram wsp\u00f3\u0142pracy powstaje poprzez przeanalizowanie diagramu sekwencji i opisanie jego interakcji z diagramem klas. Podsumowuj\u0105c, ten diagram pokazuje przep\u0142yw komunikat\u00f3w mi\u0119dzy obiektami oraz podstawowe zwi\u0105zki (relacje) mi\u0119dzy klasami<\/li>\n
- Diagram czasowy<\/b> \u2013 to diagram, kt\u00f3ry bada zachowania jednego lub wi\u0119cej obiekt\u00f3w w danym okresie czasu.<\/li>\n
- Diagram przegl\u0105dowy interakcji<\/b> \u2013 to diagram interakcji i sterowania przep\u0142ywem mi\u0119dzy diagramami interakcji (diagram sekwencji, diagram komunikacji, diagram czasowy, diagram przegl\u0105dowy interakcji).<\/li>\n<\/ul>\n
Profil UML<\/h3>\n
Profil UML to nie jest dok\u0142adnie diagramem, ale profil s\u0142u\u017c\u0105cy do opisu rozszerze\u0144 i podzbior\u00f3w UML. Podzbiory s\u0105 opisywane za pomoc\u0105 J\u0119zyka Ogranicze\u0144 Obiekt\u00f3w (OCL). Rozszerzenia tworzy si\u0119 poprzez zdefiniowanie stereotyp\u00f3w, kt\u00f3re s\u0105 etykietami, kt\u00f3re mog\u0105 ozdabia\u0107 dowolny element modelu. Na przyk\u0142ad mo\u017cemy oznaczy\u0107 klas\u0119 jako \u201etrwa\u0142\u0105\u201d i u\u017cy\u0107 tej etykiety do identyfikacji klasy, kt\u00f3rej instancje s\u0105 przechowywane po zako\u0144czeniu dzia\u0142ania systemu. Nieformalnie \u2013 i to jest ideologicznie niepoprawne \u2013 profil to dowolny zbi\u00f3r rozszerze\u0144 i podzbior\u00f3w UML, niezale\u017cnie od tego, czy s\u0105 one zapisane za pomoc\u0105 tych mechanizm\u00f3w czy nie. Formalnie, profil to definicje OCL i stereotyp\u00f3w, kt\u00f3re opisuj\u0105 zasady, kt\u00f3re w UML 2 s\u0105 zapisane w pakiecie.<\/p>\n
Powi\u0105zane diagramy dla rozwoju oprogramowania<\/h3>\n
W zale\u017cno\u015bci od r\u00f3\u017cnic mi\u0119dzy metodologiami OOAD i ewolucji standard\u00f3w UML nazwy diagram\u00f3w i ich funkcje mog\u0105 si\u0119 zmienia\u0107 z czasem. Oto przyk\u0142ady diagram\u00f3w i\/lub produkt\u00f3w pracy, kt\u00f3re mog\u0105 lub nie by\u0107 cz\u0119\u015bci\u0105 UML1 lub UML2, ale mog\u0105 by\u0107 u\u017cywane w metodologiach OOAD:<\/p>\n
- \n
- Diagram kontekstu systemu<\/b><\/li>\n
- Diagram relacji encji (podobny do diagramu klas) z ERD koncepcyjnym, logicznym i fizycznym<\/b><\/li>\n
- Analiza odporno\u015bci<\/b><\/li>\n<\/ul>\n
Wnioski<\/h2>\n
Przegl\u0105dn\u0119li\u015bmy pochodzenie i definicj\u0119 UML, aby zapewni\u0107 uproszczone zrozumienie, czym jest i co mo\u017ce nam oferowa\u0107. Przegl\u0105dn\u0119li\u015bmy r\u00f3wnie\u017c, jak mo\u017cemy skorzysta\u0107 z jego zastosowania w naszym nast\u0119pnym projekcie rozwojowym, a tak\u017ce kr\u00f3tko om\u00f3wili\u015bmy widoki architektoniczne, modele i typy diagram\u00f3w dost\u0119pne w UML 2. UML to nie jest proces, ale otwarty standard graficznego j\u0119zyka modelowania do tworzenia system\u00f3w zintegrowanych z oprogramowaniem. Sk\u0142adowe potrzebne do sukcesu projektu wymagaj\u0105 trzech aspekt\u00f3w: notacji, procesu i narz\u0119dzia:<\/p>\n
\u00a0<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/Triangle-of-Success.gif\")
<\/a><\/p>\n\u00a0<\/p>\n
Tylko notacja<\/strong> \u2013 mo\u017cesz nauczy\u0107 si\u0119notacji (np. UML)<\/strong>, ale je\u015bli nie wiesz, jak jej u\u017cywa\u0107 (procesu<\/strong>), prawdopodobnie nie powiedzie si\u0119.<\/p>\n
Tylko proces<\/strong> \u2013 mo\u017cesz mie\u0107 \u015bwietny proces<\/strong>, ale je\u015bli nie potrafisz przekaza\u0107 procesu (notacja<\/strong>), prawdopodobnie nie powiedzie si\u0119. Na koniec<\/p>\n
Brak wsparcia narz\u0119dziowego<\/strong> \u2013 je\u015bli nie potrafisz skutecznie dokumentowa\u0107 artefakt\u00f3w swojej pracy (narz\u0119dzie<\/strong>), prawdopodobnie stracisz du\u017co czasu i w ko\u0144cu nie powiedzie si\u0119.<\/p>\n
\u00a0<\/p>\n
Narz\u0119dzie do automatyzacji UML<\/h2>\n
Visual Paradigm<\/a> to narz\u0119dzie automatyzuj\u0105ce, kt\u00f3re zapewnia sukces w projektach oprogramowania dzi\u0119ki:<\/p>\n
- \n
- \u0141atwe edytowanie sk\u0142adni, aby zmniejszy\u0107 potrzeb\u0119 zapami\u0119tywania notacji<\/li>\n
- Wsparcie dla popularnych i naj\u0142atwiejszych proces\u00f3w i zestaw\u00f3w narz\u0119dzi do rozwoju oprogramowania agile scrum<\/li>\n
- Automatyzacja do wyg\u0142adzenia dla projekt\u00f3w i raport\u00f3w produktu dowolnego rozmiaru w czasie rzeczywistym<\/li>\n<\/ol>\n
Zasoby UML<\/h2>\n
- \n
- Kompletny przewodnik po 14 typach diagram\u00f3w UML \u2013 Cybermedian<\/strong>\n
- \n
- Ten przewodnik zawiera przegl\u0105d 14 typ\u00f3w diagram\u00f3w UML obs\u0142ugiwanych przez wersj\u0119 spo\u0142eczno\u015bciow\u0105 Visual Paradigm. Wyja\u015bnia, jak diagramy UML pomagaj\u0105 w wizualizacji system\u00f3w intensywnie wykorzystuj\u0105cych oprogramowanie, a tak\u017ce opisuje funkcjonalno\u015b\u0107 oferowan\u0105 przez ka\u017cdy typ diagramu. Przewodnik r\u00f3wnie\u017c podkre\u015bla zr\u00f3\u017cnicowanie Visual Paradigm w obs\u0142udze r\u00f3\u017cnych typ\u00f3w diagram\u00f3w UML w r\u00f3\u017cnych potrzebach modelowania11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Naucz si\u0119 modelowania UML za pomoc\u0105 najlepszych darmowych narz\u0119dzi UML (online i desktopowych) \u2013 Cybermedian<\/strong>\n
- \n
- Ten artyku\u0142 omawia korzy\u015bci z u\u017cywania Visual Paradigm do modelowania UML, podkre\u015blaj\u0105c wsparcie dla najnowszego standardu UML 2.x oraz szeroki zakres typ\u00f3w diagram\u00f3w. Wspomina r\u00f3wnie\u017c o mo\u017cliwo\u015bciach integracji narz\u0119dzia z popularnymi platformami programistycznymi oraz jego szerokim zastosowaniu w akademii i przemy\u015ble12<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Nauka na przyk\u0142adach: Diagramy maszyn stan\u00f3w UML \u2013 Cybermedian<\/strong>\n
- \n
- Ten zas\u00f3b skupia si\u0119 na diagramach maszyn stan\u00f3w UML i rekomenduje Visual Paradigm jako idealne narz\u0119dzie do tworzenia tych diagram\u00f3w. Zapewnia szczeg\u00f3\u0142owy przegl\u0105d sposobu, w jaki diagramy maszyn stan\u00f3w mog\u0105 modelowa\u0107 zachowanie dynamiczne systemu, a tak\u017ce podkre\u015bla integracj\u0119 Visual Paradigm z narz\u0119dziami i platformami programistycznymi13<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Diagramy UML: Kompletny przewodnik \u2013 Cybermedian<\/strong>\n
- \n
- Ten kompletny przewodnik wyja\u015bnia znaczenie diagram\u00f3w UML w rozwoju oprogramowania oraz spos\u00f3b, w jaki Visual Paradigm wspiera r\u00f3\u017cne typy diagram\u00f3w UML. Omawia diagramy strukturalne, behawioralne i interakcyjne, dostarczaj\u0105c wgl\u0105d\u00f3w na to, jak mo\u017cna wykorzysta\u0107 Visual Paradigm do tworzenia skutecznych modeli UML14<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- BEZP\u0141ATNY Narz\u0119dzie online do diagram\u00f3w UML \u2013 Cybermedian<\/strong>\n
- \n
- Ten artyku\u0142 wprowadza Visual Paradigm Online (VP Online) Express Edition \u2013 bezp\u0142atny narz\u0119dzie internetowy do tworzenia diagram\u00f3w UML. Wyr\u00f3\u017cnia \u0142atwo\u015b\u0107 u\u017cytkowania narz\u0119dzia, brak ogranicze\u0144 oraz zgodno\u015b\u0107 z r\u00f3\u017cnymi przegl\u0105darkami internetowymi, co czyni go dost\u0119pne rozwi\u0105zaniem do tworzenia diagram\u00f3w UML na potrzeby osobiste i niekomercyjne15<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Zrozumienie diagram\u00f3w czasowych UML: Kompletny przewodnik \u2013 Cybermedian<\/strong>\n
- \n
- Ten przewodnik wyja\u015bnia diagramy czasowe UML oraz ich znaczenie w systemach czasu rzeczywistego. Omawia spos\u00f3b, w jaki mo\u017cna wykorzysta\u0107 Visual Paradigm do tworzenia tych diagram\u00f3w, skupiaj\u0105c si\u0119 na wizualnym przedstawieniu ogranicze\u0144 czasowych i trwania w systemie16<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Kompletny przewodnik do diagram\u00f3w UML 2.5 \u2013 Cybermedian<\/strong>\n
- \n
- Ten przewodnik zawiera przegl\u0105d diagram\u00f3w UML 2.5 i wyr\u00f3\u017cnia Visual Paradigm jako pierwszy wyb\u00f3r w zakresie kompletnego modelowania. Omawia elastyczno\u015b\u0107 narz\u0119dzia, przyjazny interfejs u\u017cytkownika oraz mocne mo\u017cliwo\u015bci generowania kodu, co czyni go odpowiednim rozwi\u0105zaniem dla specjalist\u00f3w z r\u00f3\u017cnych bran\u017c17<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Kompletny przewodnik do diagramu klas UML \u2013 Cybermedian<\/strong>\n
- \n
- Ten przewodnik skupia si\u0119 na diagramach klas UML oraz sposobie, w jaki Visual Paradigm wspiera ich tworzenie. Omawia szerokie przyj\u0119cie narz\u0119dzia w \u015brodowisku akademickim oraz jego zastosowanie w projektowaniu i analizie system\u00f3w i baz danych. Przewodnik r\u00f3wnie\u017c wspomina o dost\u0119pno\u015bci przyk\u0142ad\u00f3w i szablon\u00f3w do szybkiego rozpocz\u0119cia modelowania UML18<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Poradnik do diagramu pakiet\u00f3w UML za pomoc\u0105 Visual Paradigm \u2013 Cybermedian<\/strong>\n
- \n
- Ten poradnik przewodnik po krokach tworzenia diagramu pakiet\u00f3w UML za pomoc\u0105 Visual Paradigm. Wyja\u015bnia znaczenie diagram\u00f3w pakiet\u00f3w w organizacji du\u017cych system\u00f3w i zawiera krok po kroku instrukcje tworzenia ich za pomoc\u0105 Visual Paradigm19<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Kompletny przewodnik do modelowania wizualnego w rozwoju oprogramowania agilnego \u2013 Cybermedian<\/strong>\n
- Poradnik do diagramu pakiet\u00f3w UML za pomoc\u0105 Visual Paradigm \u2013 Cybermedian<\/strong>\n
- Kompletny przewodnik do diagramu klas UML \u2013 Cybermedian<\/strong>\n
- Kompletny przewodnik do diagram\u00f3w UML 2.5 \u2013 Cybermedian<\/strong>\n
- Zrozumienie diagram\u00f3w czasowych UML: Kompletny przewodnik \u2013 Cybermedian<\/strong>\n
- BEZP\u0141ATNY Narz\u0119dzie online do diagram\u00f3w UML \u2013 Cybermedian<\/strong>\n
- Diagramy UML: Kompletny przewodnik \u2013 Cybermedian<\/strong>\n
- Nauka na przyk\u0142adach: Diagramy maszyn stan\u00f3w UML \u2013 Cybermedian<\/strong>\n
- Naucz si\u0119 modelowania UML za pomoc\u0105 najlepszych darmowych narz\u0119dzi UML (online i desktopowych) \u2013 Cybermedian<\/strong>\n
- Ten przewodnik zawiera przegl\u0105d 14 typ\u00f3w diagram\u00f3w UML obs\u0142ugiwanych przez wersj\u0119 spo\u0142eczno\u015bciow\u0105 Visual Paradigm. Wyja\u015bnia, jak diagramy UML pomagaj\u0105 w wizualizacji system\u00f3w intensywnie wykorzystuj\u0105cych oprogramowanie, a tak\u017ce opisuje funkcjonalno\u015b\u0107 oferowan\u0105 przez ka\u017cdy typ diagramu. Przewodnik r\u00f3wnie\u017c podkre\u015bla zr\u00f3\u017cnicowanie Visual Paradigm w obs\u0142udze r\u00f3\u017cnych typ\u00f3w diagram\u00f3w UML w r\u00f3\u017cnych potrzebach modelowania11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Kompletny przewodnik po 14 typach diagram\u00f3w UML \u2013 Cybermedian<\/strong>\n
- Diagram relacji encji (podobny do diagramu klas) z ERD koncepcyjnym, logicznym i fizycznym<\/b><\/li>\n
- Diagram komunikacji<\/b>(inaczej <\/b>Diagramy wsp\u00f3\u0142pracy UML1) \u2013 to diagram, kt\u00f3ry pokazuje, jak systemy wsp\u00f3\u0142pracuj\u0105 ze sob\u0105 w celu wykonania zadania oraz relacje, kt\u00f3re musz\u0105 istnie\u0107 mi\u0119dzy nimi. Diagram wsp\u00f3\u0142pracy powstaje poprzez przeanalizowanie diagramu sekwencji i opisanie jego interakcji z diagramem klas. Podsumowuj\u0105c, ten diagram pokazuje przep\u0142yw komunikat\u00f3w mi\u0119dzy obiektami oraz podstawowe zwi\u0105zki (relacje) mi\u0119dzy klasami<\/li>\n
- Diagram aktywno\u015bci<\/b> \u2013 to diagram dynamiki systemu poprzez modelowanie przep\u0142ywu sterowania od aktywno\u015bci do aktywno\u015bci. Pokazuje, jak system (np. obiekt\/klasa) reaguje na zdarzenie wewn\u0119trzne. (Uwaga: zdarzenia zewn\u0119trzne opisuje diagram stanu). W modelowaniu proces\u00f3w biznesowych mo\u017cesz u\u017cy\u0107 tego diagramu do przedstawienia logiki przypadku u\u017cycia lub regu\u0142y biznesowej.<\/li>\n
- Diagram obiekt\u00f3w<\/b>\u2013 to diagram statycznej struktury systemu w konkretnym momencie lub sytuacji (zdj\u0119cie), ilustruj\u0105cy relacj\u0119 w systemie.<\/li>\n
- Diagramy zachowaniowe \u2013 ka\u017cdy system mo\u017ce mie\u0107 dwa aspekty: statyczny i dynamiczny. Dlatego model uznaje si\u0119 za kompletny, gdy oba aspekty s\u0105 w pe\u0142ni uwzgl\u0119dnione.\n
- Diagramy strukturalne \u2013diagramy strukturalne<\/i>reprezentuj\u0105 aspekt statyczny systemu. Te aspekty statyczne reprezentuj\u0105 te cz\u0119\u015bci diagramu, kt\u00f3re tworz\u0105 g\u0142\u00f3wn\u0105 struktur\u0119 i dlatego s\u0105 stabilne. Te cz\u0119\u015bci statyczne s\u0105 reprezentowane przez klasy, interfejsy, obiekty, komponenty i w\u0119z\u0142y.<\/li>\n
- Widok logiczny: <\/em>pokazuje, jak ta funkcjonalno\u015b\u0107 jest zaprojektowana wewn\u0105trz systemu, pod k\u0105tem jego struktury statycznej i zachowania dynamicznego; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w klas i obiekt\u00f3w (model statyczny) oraz diagram\u00f3w przej\u015b\u0107 stan\u00f3w, sekwencji, wsp\u00f3\u0142pracy i dzia\u0142ania (model dynamiczny)<\/li>\n
- Widok przypadk\u00f3w u\u017cycia:<\/em> pokazuje funkcjonalno\u015b\u0107 systemu z perspektywy zewn\u0119trznych aktor\u00f3w; opisuje si\u0119 j\u0105 za pomoc\u0105 diagram\u00f3w przypadk\u00f3w u\u017cycia i czasem diagram\u00f3w dzia\u0142ania.<\/li>\n
- Notacja<\/i><\/b>: Wizualne przedstawienie element\u00f3w modelu<\/li>\n
- Elementy modelu<\/i><\/b>: Poj\u0119cia i semantyka<\/li>\n