UML: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Infobox update)
 
(LinkTitles.)
Linia 17: Linia 17:




'''UML''' (ang. Unified Modeling Language czyli Ujednolicony Język Modelowania) to graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania elementów [[system informatyczny|systemów informatycznych]]. Umożliwia standaryzację sposobu opracowywania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak [[proces]]y przedsiębiorstwa i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy [[baza danych|baz danych]] i komponenty programowe nadające się do ponownego użycia. UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informatycznego. Modele zapisane w języku UML są jednakowo interpretowane przez wszystkie osoby zaangażowane w dany preces.
'''UML''' (ang. Unified Modeling Language czyli Ujednolicony Język Modelowania) to graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania elementów [[system informatyczny|systemów informatycznych]]. Umożliwia standaryzację sposobu opracowywania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak [[proces]]y przedsiębiorstwa i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy [[baza danych|baz danych]] i komponenty programowe nadające się do ponownego użycia. UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informatycznego. [[Modele]] zapisane w języku UML są jednakowo interpretowane przez wszystkie osoby zaangażowane w dany preces.


==Geneza==
==Geneza==
Języki modelowania obiektowego pojawiły się między połową lat siedemdziesiątych a końcem lat osiemdziesiątych. Opracowanych zostało wiele metod obiektowych, z których jednymi z najważniejszych były: [[metoda]] Boocha, metoda OOSE Jacobsona (Object- Oriented Software Engineering) i metoda OMT Rumbaugha (Object Modeling Technique).
Języki modelowania obiektowego pojawiły się między połową lat siedemdziesiątych a końcem lat osiemdziesiątych. Opracowanych zostało wiele metod obiektowych, z których jednymi z najważniejszych były: [[metoda]] Boocha, metoda OOSE Jacobsona (Object- Oriented Software Engineering) i metoda OMT Rumbaugha (Object Modeling Technique).


Oficjalny początek prac nad UML datuje się na październik 1994 roku. Wynikiem współpracy kilku firm, m.in. Rational, IBM, Hewlett-Packard, Texas Instruments, Unisys, Microsoft, był UML 1.0 - precyzyjnie zdefiniowany język modelowania. W styczniu 1997 roku UML 1.0 został przekazany Object Management Group (OMG) w odpowiedzi na zapotrzebowanie na propozycję standardu języka modelowania obiektowego.  
Oficjalny początek prac nad UML datuje się na październik 1994 roku. Wynikiem współpracy kilku firm, m.in. Rational, IBM, Hewlett-Packard, Texas Instruments, Unisys, Microsoft, był UML 1.0 - precyzyjnie zdefiniowany język modelowania. W styczniu 1997 roku UML 1.0 został przekazany Object Management Group (OMG) w odpowiedzi na [[zapotrzebowanie]] na propozycję standardu języka modelowania obiektowego.  
<google>ban728t</google>
<google>ban728t</google>
Do współpracy włączyły się kolejne firmy, w wyniku czego powstała poprawiona wersja UML (numer 1.1), przyjęta ostatecznie przez OMG 14 listopada 1997. OMG Revision Task Force (RTF) przejął zadanie pielęgnacji standardu UML. Dokonał redakcyjnych poprawek i w czerwcu 1998 roku przedstawił wersję UML 1.2, a jesienią 1999 roku opublikował UML 1.3.
Do współpracy włączyły się kolejne firmy, w wyniku czego powstała poprawiona wersja UML (numer 1.1), przyjęta ostatecznie przez OMG 14 listopada 1997. OMG Revision Task Force (RTF) przejął [[zadanie]] pielęgnacji standardu UML. Dokonał redakcyjnych poprawek i w czerwcu 1998 roku przedstawił wersję UML 1.2, a jesienią 1999 roku opublikował UML 1.3.
<google>ban728t</google>
<google>ban728t</google>
==Zastosowania==
==Zastosowania==
Linia 80: Linia 80:
* ArgoUML - napisany w Javie, zaawansowane generowanie kodu i podpowiedzi, ciągle tworzony,
* ArgoUML - napisany w Javie, zaawansowane generowanie kodu i podpowiedzi, ciągle tworzony,
* Dia - ogólne narzędzie do rysowania diagramów,
* Dia - ogólne narzędzie do rysowania diagramów,
* UML Sculptor - prosty, łatwy w użyciu program do tworzenia diagramów klas,
* UML Sculptor - prosty, łatwy w użyciu [[program]] do tworzenia diagramów klas,
* Umbrello - program dla Linuksa, część KDE,
* Umbrello - program dla Linuksa, część KDE,
* UMLpad,
* UMLpad,
Linia 105: Linia 105:
Może być jedno- i dwukierunkowa, ale także nieokreślona. W tym przypadku klasy nie wpływają na siebie i mogą istnieć oraz działać oddzielnie. Asocjacje zachodzą zwykle między większą ilością klas.  
Może być jedno- i dwukierunkowa, ale także nieokreślona. W tym przypadku klasy nie wpływają na siebie i mogą istnieć oraz działać oddzielnie. Asocjacje zachodzą zwykle między większą ilością klas.  


Przykład: człowiek i firma, gdzie firma może zatrudniać wielu ludzi, ale może się zdarzyć, że jedna osoba pracuje w kilku firmach.
Przykład: człowiek i [[firma]], gdzie firma może zatrudniać wielu ludzi, ale może się zdarzyć, że jedna osoba pracuje w kilku firmach.


'''3. Agregacja częściowa.'''
'''3. [[Agregacja]] częściowa.'''
Oznaczana ciągłą linią z pustym rombem umieszczonym przy klasie określającej całość.
Oznaczana ciągłą linią z pustym rombem umieszczonym przy klasie określającej całość.
Jest to połączenie dwóch klas w relacji całość - część, czyli klasa całościowa dobiera sobie do działania klasy częściowe. Jeśli jedna z klas zostanie usunięta, druga może bez niej funkcjonować. Dodatkowo jedna klasa częściowa może być zawierana przez wiele innych klas całościowych, ponieważ żadna z nich nie tworzy i nie używa jej na wyłączność.
Jest to połączenie dwóch klas w relacji całość - część, czyli klasa całościowa dobiera sobie do działania klasy częściowe. Jeśli jedna z klas zostanie usunięta, druga może bez niej funkcjonować. Dodatkowo jedna klasa częściowa może być zawierana przez wiele innych klas całościowych, ponieważ żadna z nich nie tworzy i nie używa jej na wyłączność.
Linia 117: Linia 117:
Jest bardzo podobna do agregacji częściowej, z tą różnicą, że po usunięciu klasy głównej, przestają istnieć także klasy częściowe. Dzieje się tak, ponieważ to klasa całościowa tworzy klasy częściowe.  
Jest bardzo podobna do agregacji częściowej, z tą różnicą, że po usunięciu klasy głównej, przestają istnieć także klasy częściowe. Dzieje się tak, ponieważ to klasa całościowa tworzy klasy częściowe.  


Przykład: faktura i pozycje faktury.
Przykład: [[faktura]] i pozycje faktury.


'''5. Generalizacja.'''
'''5. Generalizacja.'''
Linia 128: Linia 128:
* Górski T., Sowa M. (2016). [https://www.researchgate.net/profile/Tomasz_Gorski/publication/299382801_Konstrukcja_diagramu_klas_UML_z_zastosowaniem_Model-Driven_Development/links/56fe3fab08ae1408e15cfaf6/Konstrukcja-diagramu-klas-UML-z-zastosowaniem-Model-Driven-Development.pdf ''Konstrukcja diagramu klas UML z zastosowaniem Model-Driven Development''], Wojskowa Akademia Techniczna, Wydział Cybernetyki, Instytut Systemów Informatycznych, nr 1  
* Górski T., Sowa M. (2016). [https://www.researchgate.net/profile/Tomasz_Gorski/publication/299382801_Konstrukcja_diagramu_klas_UML_z_zastosowaniem_Model-Driven_Development/links/56fe3fab08ae1408e15cfaf6/Konstrukcja-diagramu-klas-UML-z-zastosowaniem-Model-Driven-Development.pdf ''Konstrukcja diagramu klas UML z zastosowaniem Model-Driven Development''], Wojskowa Akademia Techniczna, Wydział Cybernetyki, Instytut Systemów Informatycznych, nr 1  
* Plebaniak R. (2013). [http://www.math.uni.lodz.pl/~robpleb/wyklad1_3.pdf ''Modelowanie i analiza systemów informatycznych'']
* Plebaniak R. (2013). [http://www.math.uni.lodz.pl/~robpleb/wyklad1_3.pdf ''Modelowanie i analiza systemów informatycznych'']
* Stevens P. (2007). ''UML. Inżynieria oprogramowania.'', Wydanie II, Wydawnictwo Helion, Gliwice
* Stevens P. (2007). ''UML. [[Inżynieria oprogramowania]].'', Wydanie II, Wydawnictwo Helion, Gliwice
* Szlenk M. (2005). [http://www.ia.pw.edu.pl/~mszlenk/pdf/PhD-Thesis.pdf ''Formalna semantyka i wnioskowanie o pojęciowym diagramie klas w UML''], Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych
* Szlenk M. (2005). [http://www.ia.pw.edu.pl/~mszlenk/pdf/PhD-Thesis.pdf ''Formalna semantyka i wnioskowanie o pojęciowym diagramie klas w UML''], Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych
* Szmuc W. (2007). [http://journals.bg.agh.edu.pl/AUTOMATYKA/2007-1-2/Auto24.pdf ''Modelowanie konstrukcji obiektowych języka UML z zastosowaniem kolorowanych sieci Petriego''], tom 11
* Szmuc W. (2007). [http://journals.bg.agh.edu.pl/AUTOMATYKA/2007-1-2/Auto24.pdf ''Modelowanie konstrukcji obiektowych języka UML z zastosowaniem kolorowanych sieci Petriego''], tom 11

Wersja z 06:53, 22 maj 2020

UML
Polecane artykuły



UML (ang. Unified Modeling Language czyli Ujednolicony Język Modelowania) to graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania elementów systemów informatycznych. Umożliwia standaryzację sposobu opracowywania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak procesy przedsiębiorstwa i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy baz danych i komponenty programowe nadające się do ponownego użycia. UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informatycznego. Modele zapisane w języku UML są jednakowo interpretowane przez wszystkie osoby zaangażowane w dany preces.

Geneza

Języki modelowania obiektowego pojawiły się między połową lat siedemdziesiątych a końcem lat osiemdziesiątych. Opracowanych zostało wiele metod obiektowych, z których jednymi z najważniejszych były: metoda Boocha, metoda OOSE Jacobsona (Object- Oriented Software Engineering) i metoda OMT Rumbaugha (Object Modeling Technique).

Oficjalny początek prac nad UML datuje się na październik 1994 roku. Wynikiem współpracy kilku firm, m.in. Rational, IBM, Hewlett-Packard, Texas Instruments, Unisys, Microsoft, był UML 1.0 - precyzyjnie zdefiniowany język modelowania. W styczniu 1997 roku UML 1.0 został przekazany Object Management Group (OMG) w odpowiedzi na zapotrzebowanie na propozycję standardu języka modelowania obiektowego.

Do współpracy włączyły się kolejne firmy, w wyniku czego powstała poprawiona wersja UML (numer 1.1), przyjęta ostatecznie przez OMG 14 listopada 1997. OMG Revision Task Force (RTF) przejął zadanie pielęgnacji standardu UML. Dokonał redakcyjnych poprawek i w czerwcu 1998 roku przedstawił wersję UML 1.2, a jesienią 1999 roku opublikował UML 1.3.

Zastosowania

Głównym przeznaczeniem UML jest budowa systemów informatycznych.Z powodzeniem stosowano go już w:

Służy do modelowania dziedziny problemu - w przypadku stosowania go do analizy oraz do modelowania rzeczywistości, która ma dopiero powstać - tworzy się w nim głównie modele systemów informatycznych. UML jest głównie używany wraz z jego reprezentacją graficzną - jego elementom przypisane są symbole, które wiązane są ze sobą na diagramach. Uniwersalnym formatem zapisu języka UML jest XMI - język służący do zapisywania modeli UML za pomocą XML'a.

Elementy składowe

W najnowszej wersji 2.0 języka UML wyróżnia się 13 diagramów głównych, oraz 4 abstrakcyjne (struktur, dynamiki, wdrożeniowe, interakcji):

Diagramy struktury

  • Klas (class),
  • Obiektów (object),
  • Pakietów,
  • Struktur połączonych.

Diagramy wdrożeniowe (abstrakcyjne)

  • Komponentów,
  • Rozlokowania.

Diagramy dynamiki

  • Przypadków użycia (use case),
  • Czynności (activity),
  • Maszyny stanowej (state).

Diagramy interakcji

  • Sekwencji,
  • Komunikacji,
  • Harmonogramowania (lub Zależności czasowych),
  • Sterowania interakcją.

Zastosowania w projektowaniu systemów informatycznych

Projektując system informatyczny, rozpoczyna się przeważnie od tworzenia diagramów w następującej kolejności:

  • Przypadków użycia,
  • Klas,
  • Czynności,
  • Sekwencji.

Są to najczęściej wykorzystywane diagramy. Pozostałe z nich bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych.

UML nie jest językiem programowania graficznego, jednak modele w nim zapisane mogą być wprost powiązane z wieloma językami programowania. Model utworzony w języku UML można przekształcić w taki język, jak Java, C++ czy Visual Basic, albo w tabele relacyjnej bazy danych. To przekształcenie umożliwia inżynierię do przodu, to znaczy generowanie kodu w języku programowania na podstawie modelu UML. Możliwe jest także odwrotne przekształcenie, czyli rekonstrukcja modelu na podstawie implementacji (inżynieria wstecz). Przy przejęciu od modelu do kodu każda informacja niezakodowana w implementacji jest tracona, dlatego inżynieria wstecz wymaga odpowiednich narzędzi i udziału człowieka. UML jest na tyle wyrazisty i jednoznaczny, że umożliwia nie tylko bezpośrednie przekształcanie modeli, ale także symulację systemów oraz dostrajanie elementów wdrożonych systemów.

Wybrane aplikacje wspomagające tworzenie diagramów

Darmowe:

  • ArgoUML - napisany w Javie, zaawansowane generowanie kodu i podpowiedzi, ciągle tworzony,
  • Dia - ogólne narzędzie do rysowania diagramów,
  • UML Sculptor - prosty, łatwy w użyciu program do tworzenia diagramów klas,
  • Umbrello - program dla Linuksa, część KDE,
  • UMLpad,
  • JUDE Community.

Narzędzia komercyjne:

  • Borland Together - rodzina programów integrujących się z różnymi IDE, jest wersja darmowa,
  • Poseidon for UML - zaawansowane narzędzie bazujące na ArgoUML, darmowa edycja Community,
  • Enterprise Architect - Profesjonalne narzędzie w przystępnej cenie o wygodnym interfejsie działające na platformach Windows i Linux. Wspiera UML 2.0,
  • Rodzina programów iGrafx - narzędzia począwszy od iGrafx FlowCharter wspierają tworzenie diagramów UML. Wersja testowa na witrynie iGrafx,
  • Visual Paradigm for UML,
  • IBM Rational Rose,
  • Telelogic Tau G2.

Rodzaje związków między klasami

Rys. 1. Rodzaje zależności

1. Zależność. Oznaczana przez przerywaną linią i kończąca się strzałką wskazującą kierunek zależności. Relacja ta oznacza, że jedna klasa (A) w jakiś sposób korzysta z drugiej klasy (B). Przykładowo klasa A może wywoływać różne działania w klasie B bądź też może wymagać jej do poprawnego stworzenia swojej instancji. W przypadku zmian w klasie A, klasa B zwykle też musi być zmieniona. Obie klasy są wymagane do poprawnego działania.

Przykład: Sklep i płatności internetowe.

2. Asocjacja. Oznaczona linią ciągłą, zakończoną strzałką wskazującą kierunek zależności. Może być jedno- i dwukierunkowa, ale także nieokreślona. W tym przypadku klasy nie wpływają na siebie i mogą istnieć oraz działać oddzielnie. Asocjacje zachodzą zwykle między większą ilością klas.

Przykład: człowiek i firma, gdzie firma może zatrudniać wielu ludzi, ale może się zdarzyć, że jedna osoba pracuje w kilku firmach.

3. Agregacja częściowa. Oznaczana ciągłą linią z pustym rombem umieszczonym przy klasie określającej całość. Jest to połączenie dwóch klas w relacji całość - część, czyli klasa całościowa dobiera sobie do działania klasy częściowe. Jeśli jedna z klas zostanie usunięta, druga może bez niej funkcjonować. Dodatkowo jedna klasa częściowa może być zawierana przez wiele innych klas całościowych, ponieważ żadna z nich nie tworzy i nie używa jej na wyłączność.

Przykład: samochód i wypożyczający.

4. Agregacja całkowita. Oznaczana linią ciągłą z wypełnionym rombem, który jest umieszczony przy klasie całościowej. Jest bardzo podobna do agregacji częściowej, z tą różnicą, że po usunięciu klasy głównej, przestają istnieć także klasy częściowe. Dzieje się tak, ponieważ to klasa całościowa tworzy klasy częściowe.

Przykład: faktura i pozycje faktury.

5. Generalizacja. Oznaczana przez linię ciągłą zakończoną niewypełnionym trójkątem skierowanym z klasy pochodnej do klasy bazowej. Wyodrębnia wspólne cechy dla kilku klas i przenosi je do klasy bardziej ogólnej. Klasy pochodne dziedziczą cechy i zachowania klasy bazowej, ale też zwykle dodają własne lub nadpisując istniejące.

Przykład: pies i kot dziedziczące po klasie zwierzę. Wspólną cechą będzie ilość nóg, a zachowaniem chodzenie, natomiast różnić się mogą odpowiednio ulubionym jedzeniem oraz wydawanymi dźwiękami.

Bibliografia

Autor: Magdalena Adamczyk, Mateusz Bembenek, Aleksandra Zembaty