{"id":29130,"date":"2021-09-01T12:36:20","date_gmt":"2021-09-01T10:36:20","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/podstawy-uml-czyli-modelowanie-dla-kazdego\/"},"modified":"2024-11-07T15:41:03","modified_gmt":"2024-11-07T14:41:03","slug":"podstawy-uml-czyli-modelowanie-dla-kazdego","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/podstawy-uml-czyli-modelowanie-dla-kazdego\/","title":{"rendered":"Podstawy UML \u2013 czyli modelowanie dla ka\u017cdego"},"content":{"rendered":"\n
\n

<\/p>\n

    \n
  1. 1. UML dla ka\u017cdego<\/a><\/li>\n
  2. 2. Outsourcing specjalisty IT \u2013 UML w praktyce<\/a><\/li>\n
  3. 3. Zastosowanie diagram\u00f3w UML \u2013 podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    UML dla ka\u017cdego<\/strong><\/h2>\n\n\n\n

    Notacja UML<\/a><\/strong> umo\u017cliwia opisanie za\u0142o\u017ce\u0144, jak i dokumentowanie istniej\u0105cego systemu w spos\u00f3b graficzny w postaci dedykowanych diagram\u00f3w. Diagramy te pozwalaj\u0105 na formalne opisywanie i modelowanie struktur czy proces\u00f3w w spos\u00f3b zrozumia\u0142y zar\u00f3wno dla zespo\u0142u technicznego, jak i interesariuszy.<\/p>\n\n\n\n

    Diagramy UML dzielimy na te, kt\u00f3re opisuj\u0105 struktur\u0119, jak np. diagram klas czy komponent\u00f3w, oraz diagramy, za pomoc\u0105 kt\u00f3rych modelujemy zachowanie systemu \u2013 jak np. diagram przypadk\u00f3w u\u017cycia, aktywno\u015bci czy diagram sekwencji.<\/p>\n\n\n\n

    Spr\u00f3buj\u0119 w spos\u00f3b praktyczny przybli\u017cy\u0107 \u015bwiat UML na podstawie bliskiego Inetum przyk\u0142adu, a mianowicie outsourcingu pracownik\u00f3w oraz ca\u0142ego procesu od momentu zapytania o danego specjalist\u0119 do momentu rozpocz\u0119cia wsp\u00f3\u0142pracy. Aby przybli\u017cy\u0107 podstawy UML (a tym samym zach\u0119ci\u0107 do stosowania i czytania diagram\u00f3w UML), zastosuj\u0119 uproszczon\u0105 form\u0119 zapisu tego procesu.<\/p>\n\n\n\n

    Przeczytaj tak\u017ce: UML i BPMN \u2013 narz\u0119dzia pracy analityczki i analityka<\/a><\/strong><\/p>\n\n\n\n

    Outsourcing specjalisty IT \u2013 UML w praktyce<\/h2>\n\n\n\n

    Wyobra\u017amy sobie, \u017ce dana firma rozwija system finansowy i jest zainteresowana wynajmem pracownika specjalizuj\u0105cego si\u0119 w danej dziedzinie (programista, tester, analityk), posiadaj\u0105cego okre\u015blone kompetencje. Do wyspecyfikowania cech, kt\u00f3re b\u0119d\u0105 istotne, mo\u017ce pos\u0142u\u017cy\u0107 diagram klas, kt\u00f3ry opisze pracownika oraz jego kompetencje.<\/p>\n\n\n\n

    Diagram klas<\/h3>\n\n\n\n

    Diagram klas obrazuje zbi\u00f3r klas, interfejs\u00f3w oraz zale\u017cno\u015bci pomi\u0119dzy nimi. Pozwala na szczeg\u00f3\u0142owy opis klas ze zwr\u00f3ceniem uwagi na dost\u0119pne atrybuty i operacje.<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"UML<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    Pomi\u0119dzy klasami mog\u0105 wyst\u0119powa\u0107 relacje jednokierunkowe lub dwukierunkowe, jak dziedziczenie, zale\u017cno\u015bci pomi\u0119dzy klasami czy przypisanie element\u00f3w jednej klasy do drugiej.<\/p>\n\n\n\n

    W naszym przyk\u0142adzie ka\u017cdy pracownik ma przypisane stanowisko nale\u017c\u0105ce do danego dzia\u0142u. Dodatkowo pracownik posiada wiele kompetencji okre\u015blonych przez klas\u0119 Kompetencje.<\/strong><\/p>\n\n\n\n

    M\u00f3wi\u0105c o procesie, chcemy zidentyfikowa\u0107 osoby bior\u0105ce w nim udzia\u0142. W notacji UML takie osoby s\u0105 nazywane aktorami. <\/strong>Aktor jest rol\u0105, kt\u00f3r\u0105 u\u017cytkownik pe\u0142ni w stosunku do systemu oraz przypadk\u00f3w u\u017cycia \u2013 mo\u017ce nim by\u0107 cz\u0142owiek, urz\u0105dzenie lub inny system. Maj\u0105c okre\u015blonych aktor\u00f3w, zaczynamy modelowanie z wykorzystaniem diagramu przypadk\u00f3w u\u017cycia.<\/p>\n\n\n\n

    Diagram przypadk\u00f3w u\u017cycia<\/h3>\n\n\n\n

    Diagram ten odgrywa najwa\u017cniejsz\u0105 rol\u0119 w procesie projektowania systemu. Opisuje on wymagania systemu oraz identyfikuje funkcjonalno\u015bci, jakie zawiera.<\/p>\n\n\n\n

    Wymagania funkcjonalne systemu definiujemy za pomoc\u0105 przypadk\u00f3w u\u017cycia, kt\u00f3re w spos\u00f3b graficzny reprezentuj\u0105 te wymagania. Przypadki u\u017cycia (PU) nazywaj\u0105 dan\u0105 funkcjonalno\u015b\u0107 systemu, opisuj\u0105 zale\u017cno\u015bci, w kt\u00f3rych dany przypadek wyst\u0105pi, oraz opisuj\u0105 scenariusze kolejno wykonywanych czynno\u015bci s\u0142u\u017c\u0105cych do zrealizowania danego PU. Przyk\u0142adowo scenariusze opisuj\u0105ce PU s\u0105 podstaw\u0105 dla tworzenia przypadk\u00f3w testowych danego zakresu aplikacji.<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"UML<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    Jak wygl\u0105da\u0142oby zastosowanie modelu przypadk\u00f3w u\u017cycia w kontek\u015bcie outsourcingu? Model w jasny spos\u00f3b prezentuje, kt\u00f3ry aktor (klient, pracownik dzia\u0142u sprzeda\u017cy, programista, manager) jest zwi\u0105zany z dan\u0105 cz\u0119\u015bci\u0105 procesu. Klient zg\u0142asza zapotrzebowanie na danego specjalist\u0119, osoba z dzia\u0142u sprzeda\u017cy weryfikuje, czy istnieje pracownik o wymaganych kompetencjach, i potwierdza jego dost\u0119pno\u015b\u0107 z prze\u0142o\u017conym. Po znalezieniu konkretnej osoby mo\u017ce (ale nie musi) odby\u0107 si\u0119 rozmowa techniczna weryfikuj\u0105ca umiej\u0119tno\u015bci kandydata.<\/p>\n\n\n\n

    –><\/strong> include<\/strong> (zwi\u0105zek zawierania) rozszerza funkcjonalno\u015b\u0107 bazowego PU. W naszym przypadku oznacza, \u017ce funkcjonalno\u015b\u0107 zam\u00f3wienia specjalisty zawsze wi\u0105\u017ce si\u0119 z weryfikacj\u0105 dost\u0119pnych pracownik\u00f3w.<\/p>\n\n\n\n

    <– extend<\/strong> (zwi\u0105zek rozszerzania) wskazuje, \u017ce dany PU opcjonalnie rozszerza funkcjonalno\u015b\u0107 PU bazowego. W omawianym przyk\u0142adzie weryfikacja techniczna nie jest cz\u0119\u015bci\u0105 konieczn\u0105 procesu rekrutacji.<\/p>\n\n\n\n

    Diagram sekwencji<\/h3>\n\n\n\n

    Ten sam proces mo\u017cna zamodelowa\u0107, bior\u0105c pod uwag\u0119 przep\u0142ywy pomi\u0119dzy aktorami\/systemami z uwzgl\u0119dnieniem czasu oraz komunikat\u00f3w (interakcji).<\/p>\n\n\n\n

    S\u0142u\u017cy do prezentowania interakcji pomi\u0119dzy obiektami wraz z uwzgl\u0119dnieniem w czasie komunikat\u00f3w, jakie s\u0105 przesy\u0142ane pomi\u0119dzy nimi. Obiektami wchodz\u0105cymi w interakcje mog\u0105 by\u0107 aktorzy oraz obiekty wewn\u0119trzne lub zewn\u0119trzne (systemy) komunikuj\u0105ce si\u0119 pomi\u0119dzy sob\u0105.<\/p>\n\n\n\n

    Poni\u017cej przedstawiony zosta\u0142 uproszczony przebieg procesu zam\u00f3wienia oraz pozytywnej weryfikacji pracownika zako\u0144czony podj\u0119ciem decyzji o wsp\u00f3\u0142pracy z kandydatem.<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"UML<\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    Po zapytaniu klienta o specjalist\u0119 o danych kompetencjach pracownik dzia\u0142u sprzeda\u017cy weryfikuje, czy istnieje taki pracownik, u\u017cywaj\u0105c do tego systemu ewidencji pracownik\u00f3w (JMatrix). W przypadku negatywnej weryfikacji klient natychmiast otrzymuje odpowied\u017a i na tym ko\u0144czy si\u0119 proces. Dla pozytywnej weryfikacji nale\u017cy dodatkowo sprawdzi\u0107 dost\u0119pno\u015b\u0107 pracownika \u2013 w tym celu pracownik dzia\u0142u sprzeda\u017cy kontaktuje si\u0119 z prze\u0142o\u017conym pracownika.<\/p>\n\n\n\n

    W przypadku dost\u0119pno\u015bci pracownika mo\u017ce nast\u0105pi\u0107 rozmowa kwalifikuj\u0105ca go do projektu przeprowadzona przez klienta. Ca\u0142y proces ko\u0144czy si\u0119 uzgodnieniem warunk\u00f3w wsp\u00f3\u0142pracy oraz przekazaniem informacji o rozpocz\u0119ciu pracy w projekcie.<\/p>\n\n\n\n

    Zastosowanie diagram\u00f3w UML \u2013 podsumowanie<\/h2>\n\n\n\n

    Jak pokaza\u0142 powy\u017cszy przyk\u0142ad, UML mo\u017ce s\u0142u\u017cy\u0107 nie tylko do opisywania skomplikowanych proces\u00f3w systemu, ale i do graficznego przedstawienia wielu czynno\u015bci zar\u00f3wno biznesowych, jak i z \u017cycia codziennego. To tylko namiastka ogromu mo\u017cliwo\u015bci, r\u00f3\u017cnorodnych diagram\u00f3w oraz powi\u0105za\u0144, kt\u00f3re wykorzystuje si\u0119 w modelowaniu za pomoc\u0105 UML. Niew\u0105tpliwie jest to doskona\u0142e narz\u0119dzie do precyzyjnego opisania ka\u017cdego systemu informatycznego oraz dokumentowania wszelkich jego zawi\u0142o\u015bci.<\/p>\n\n\n\n

    Przeczytaj tak\u017ce: 7 grzech\u00f3w g\u0142\u00f3wnych w analizie biznesowej<\/a><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

    Jedn\u0105 z najwa\u017cniejszych rzeczy w procesie produkcji oprogramowania jest w\u0142a\u015bciwe zrozumienie wymaga\u0144 w zakresie tworzonego systemu. Naturalny j\u0119zyk opisywania potrzeb interesariuszy mo\u017ce nie by\u0107 precyzyjny i jednoznaczny. Trudno z jego pomoc\u0105 opisa\u0107 wszystkie powi\u0105zania, wp\u0142yw jednej cz\u0119\u015bci systemu na pozosta\u0142e, tak aby by\u0142o to zrozumia\u0142e zar\u00f3wno dla os\u00f3b nietechnicznych, jak i zespo\u0142u wytwarzaj\u0105cego oprogramowanie. Chc\u0105c u\u0142atwi\u0107 komunikacj\u0119, zadba\u0107 o w\u0142a\u015bciwe zrozumienie i zaprojektowa\u0107 wszystkie interakcje w systemie, podczas opisywania systemu u\u017cywamy j\u0119zyka UML (Unified Modelling Language). W artykule postaram si\u0119 nakre\u015bli\u0107 podstawy UML i przekona\u0107, \u017ce modelowanie mo\u017ce u\u0142atwi\u0107 zrozumienie i zobrazowanie dowolnych proces\u00f3w.<\/p>\n","protected":false},"author":165,"featured_media":29141,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":1650,"footnotes":""},"categories":[1,583],"tags":[],"offering":[522],"class_list":["post-29130","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-zarzadzanie-projektami","offering-tech-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/165"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=29130"}],"version-history":[{"count":3,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29130\/revisions"}],"predecessor-version":[{"id":33967,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29130\/revisions\/33967"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/29141"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=29130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=29130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=29130"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=29130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}