====== UML w analizie i projektowaniu ======


Booch, Rambaugh i Jacobson połączyli zalety opracowanych przez siebie metod analizy i projektowania i stworzyli nową metodę, którą nazwali UML( ang. Unified Modeling Language).

UML umożliwia opisanie analizowanego systemu z pięciu „perspektyw” uwzględniających  różne aspekty oprogramowania. Każdej perspektywie odpowiada zestaw diagramów. 

  * Perspektywa przypadków użycia

czyli obraz systemu widziany oczami użytkownika(Aktor). W tej perspektywie system modeluje się, opisując przypadki użycia.

  * Perspektywa projektowa
 
czyli dane i funkcje systemu widziane z jego wnętrza. Modeluje się w niej statyczną strukturę oprogramowania ,czyli klasy, obiekty , związki

  * Perspektywa procesowa
 
w której opisuje się dynamiczne aspekty systemu, rozważa się w niej mechanizmy interakcji lub kooperacji miedzy elementami widocznymi w perspektywie przypadków użycia i w perspektywie projektowej.
 
  * Perspektywa implementacyjna


czyli sposób konstrukcji statycznych i dynamicznych aspektów systemu 

  * Perspektywa wdrożeniowa
 
czyli związki statycznych i dynamicznych aspektów systemu ze środowiskiem, w którym będzie on zaimplementowany.

W analizie obiektowej z użyciem UML najwięcej uwagi poświęca się perspektywie przypadków użycia i perspektywie projektowej. Perspektywy procesową, implementacyjną i wdrożeniową uwzględnia się w fazie projektowania obiektowego. Metoda analizy obiektowej UML obejmuje stworzenie reprezentacji i hierarchii klas, modeli obiekt-związek oraz modeli zachowania obiektu.

Do analizy systemu posługujemy się następującymi diagramami: diagramy klas i diagramy przypadków użycia, diagramy stanów systemu i diagramy sekwencji, diagramy aktywności

===== Diagram przypadków użycia =====


[[diagramy_przypadkow_uzycia|Więcej ...]]

===== Diagramy klas =====


Diagramy klas to najczęściej występujące diagramy w modelach obiektowych. Każdy z
nich przedstawia określony fragment struktury systemu klas. Diagramów klas używa się
do modelowania statycznych aspektów perspektywy projektowej. Wiąże się z tym w
głównej mierze modelowanie słownictwa systemu, kooperacji lub schematów.
Diagramy klas stanowią bazę wyjściową do dwóch innych diagramów: diagramu
komponentów i diagramu wdrożenia.

{{:diagram_klas.jpg|:diagram_klas.jpg}}

===== Diagramy sekwencji =====


Diagramy sekwencji posiadają dwa wymiary: wymiar pionowy reprezentuje czas, zaś wymiar
poziomy reprezentuje różne obiekty (kolejność obiektów nie ma znaczenia). Orientację wymiarów można zmienić: obiekty mogą być zaprezentowane w wymiarze pionowym, zaś czas w wymiarze poziomym. Generalnie, istotna jest kolejność pewnych zdarzeń, natomiast nie jest istotna  rzeczywista miara czasu. Obiekty są zaznaczane w postaci prostokątów z wpisaną wewnątrz nazwą obiektu (klasy). Od każdego obiektu prowadzi linia reprezentująca „linię życia” obiektu. Na tych liniach zaznacza się momenty wysłania komunikatów przez dany obiekt do innego obiektu w postaci strzałek prowadzących od jednej linii do innej linii. Diagram taki może także pokazywać pewne akcje zachodzące równolegle.

{{:diagram_sekwencji.jpg|:diagram_sekwencji.jpg}}

===== Diagramy stanów =====


Diagram stanów w swojej idei nawiązuje do automatu skończonego. Opisuje on stany pewnego procesu, które są istotne z punktu widzenia modelu pojęciowego tego procesu, oraz przejścia pomiędzy stanami. Stany, w istocie reprezentujące stany sterowania procesu, przedstawiane są  w postaci prostokątów z zaokrąglonymi rogami. Przejścia pomiędzy stanami zostały zaznaczone w postaci strzałek. Tego rodzaju diagramy mogą być zagnieżdżane, tj. dowolny „stan” reprezentowany na diagramie może być uszczegółowiony w postaci odrębnego diagramu.

{{:diagram_stanow.jpg|:diagram_stanow.jpg}}


===== Diagramy aktywności =====


Diagramy aktywności w swej zasadniczej idei są dokładnie tym samym, co diagramy
przepływu sterowania .Jedyną różnicą koncepcyjną jest to, że pojawiają się na nich elementy synchronizacji równoległych procesów (w dość uproszczonej formie, która dla pewnych celów może być niewystarczająca). Diagramy aktywności są szczególnym przypadkiem diagramów stanów.

{{:diagram_aktywnosci.jpg|:diagram_aktywnosci.jpg}}

----

Zgodnie z metodologią UML w ramach analizy obiektowej opisuje się system z perspektywy przypadków użycia i z perspektywy projektowej. Pozwala to zrozumieć scenariusze użycia systemu( co umożliwia modelowanie zachowania), a także zidentyfikować i opisać elementy statycznej struktury systemu, a tym samym stworzyć podstawy projektu architektury.  

Projektowanie w UML odbywa się  na dwóch poziomach abstrakcji. Dzielimy ja na projektowanie podsystemów i projektowanie poszczególnych obiektów. 
Projektowanie systemów polega na definiowaniu architektury systemu obiektowego. Obejmuje to podzielenie systemu na podsystemy, zdefiniowanie  mechanizmów interakcji między nimi ( diagramy kooperacji) grupowanie podsystemów w warstwy architektury( diagramy wdrożenia) , a także projektowanie interfejsu użytkownika  oraz mechanizmów zarządzania danymi i zadaniami. Te mechanizmy stanowią infrastrukturę projektową.
Projektowanie obiektów polega na opisaniu struktur danych i algorytmów odpowiadających atrybutom i operacjom obiektów, a także komunikatów służących do realizowanie kooperacji i związków między obiektami.  
----

Do projektowania posłużymy się następującymi diagramami: diagramy kooperacji, uaktualnione diagramy klas,  diagramy komponentów, diagramy wdrożeniowe.

===== Diagram kooperacji =====


W swojej idei diagramy współpracy są podobne do diagramów sekwencji. Ich istotą jest
przedstawienie przepływu komunikatów pomiędzy obiektami. Współpraca pomiędzy obiektami włącza dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki, atrybuty i operacje (jest to nazywane „kontekstem współpracy”), oraz sekwencję komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania. Diagram współpracy może być rozrysowany dla pewnych typów obiektów, dla pewnych operacji lub dla pewnych przypadków użycia. W odróżnieniu od diagramów sekwencji wymiar czasu nie jest tu bezpośrednio odwzorowany. Natomiast odwzorowane są powiązania pomiędzy obiektami (prezentujące pewną część powiązań z diagramu klas). Jak poprzednio, obiekty są przedstawione w postaci prostokątów z wpisaną w  środku nazwą. Diagram współpracy pokazuje komunikaty przesyłane pomiędzy poszczególnymi obiektami, które służą do realizacji określonego celu. Przepływ komunikatów jest zaznaczany  strzałką, obok której znajduje się nazwa komunikatu oraz jego parametry. Notacja ta jednocześnie  odwzorowuje dwa aspekty: strukturę obiektów uczestniczących w realizacji pewnego celu oraz  zachowanie się obiektów podczas wykonywania programu. Takie diagramy mogą być obudowane dużą liczbą różnorodnych dodatkowych opcji (warunków, iteracji, stereotypów, tworzenia i usuwania obiektów, numerów sekwencji akcji, itd.).

{{:diagram_kooperacji.jpg|:diagram_kooperacji.jpg}}

===== Diagramy komponentów =====


Diagramy komponentów pokazują zależności pomiędzy komponentami oprogramowania,
włączając komponenty kodu źródłowego, kodu binarnego oraz kodu wykonywalnego.
Diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią)prowadzą do klienta pewnej informacji do jej dostawcy. Rodzaj zależności jest zależny od typu języka programowania. Diagram może także pokazywać interfejsy poszczególnych komponentów.

{{:diagram_komponentow.jpg|:diagram_komponentow.jpg}}

===== Diagram wdrożeniowy =====


Diagram wdrożeniowe pokazują konfigurację elementów czasu wykonania: komponentów
sprzętowych, komponentów oprogramowania, procesów oraz związanych z nimi obiektów.
Komponenty, które nie istnieją w trakcie czasu wykonania nie pojawiają się na tych diagramach; powinny one być pokazane na diagramach komponentów. Diagram wdrożeniowe jest grafem, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne.

{{:diagram_wdrozeniowy.jpg|:diagram_wdrozeniowy.jpg}}


**Moze sie przydac:**
{{:uml_-_opis.pdf|:uml_-_opis.pdf}}