DIAGRAM CZYNNOŚCI - (Activity Diagram) to szczególny przypadek diagramu stanów, który obrazuje strumień kolejno wykonywanych czynności. Odnosi się do modelowania dynamicznych aspektów systemu. Kładzie nacisk na przepływ sterowania miedzy obiektami.

Diagram czynności obrazuje przepływ sterowania (jest właściwie schematem blokowym). Przedstawia sekwencyjne (ew. współbieżne) kroki procesu obliczeniowego.

Diagram czynności zawiera na ogół stany (akcji i czynności), przejścia oraz obiekty. Wykonywane obliczenia nazywamy stanami (akcji lub czynności). Stany akcji i czynności są szczególnymi przypadkami stanów maszyny stanowej. Diagram czynności jest rodzajem maszyny stanowej.

DIAGRAM CZYNNOŚCI:

Diagram czynności to graficzne przedstawieniesekwencyjnych i (lub) współbieżnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów.

Diagram czynności jest przede wszystkim ogólnym spojrzeniem na to, co się dzieje podczas wykonywania operacji i w trakcie procesu.

Diagram czynności bardzo przypomina schemat blokowy.

Pokazuje kroki, punkty podejmowania decyzji i rozgałęzienia

Diagram czynności jest rozszerzeniem diagramu stanów.

Na diagramie stanów pokazywane są stany obiektu i czynności w postaci strzałek łączących te stany, i to właśnie te czynności są przede wszystkim eksponowane na diagramach czynności.

Diagramy czynności stosuje się w modelowaniu:

- wysokopoziomowych procesów biznesowych

- systemów oraz podsystemów

- scenariuszy przypadków użycia

- procesów systemowych charakteryzujących się dużą

liczbą równoległych czynności i sytuacji decyzyjnych

- operacji

- algorytmów

Diagramy czynności składają się z następujących podstawowych elementów:

- czynności

- przepływów sterowania

- początku

- końca

- zakończenia przepływu

Czynność to określone zachowanie złożone z logicznie uporządkowanych ciągów podczynności, akcji oraz obiektów w celu wykonania pewnego procesu

Akcja to elementarna jednostka specyfikacji zachowania, która reprezentuje transformację lub przetwarzanie w modelowym systemie.

Każda czynność jest reprezentowana przez zaokrąglony prostokąt - węższy i bardziej owany od ikony stanu.

Przepływ sterowania zachodzi pomiędzy kolejnymi logicznie uporządkowanymi czynnościami lub akcjami.

W szczególnych przypadkach można przypisać mu nazwę. Przepływ sterowania charakteryzuje się zdolnością przesyłania znaczników sterowania (ang. tokens).

Znaczniki sterowania to abstrakcyjne kategorie pojęciowe, użyteczne w monitorowaniu i realizacji procesu sterowania na diagramie czynności. Nie mają osobnego oznaczenia

DIAGRAM PRZYPADKÓW użycia (ang. use - case diagram ) służy do modelowania aktorów (użytkowników systemu, odbiorców efektów pracy systemu, systemów zewnętrznych) i ich potrzeb w stosunku do tworzonego systemu. Przypadki użycia prezentowane na tym diagramie to sekwencje czynności, które prowadzą do spełnienia celu przypadku użycia (zaspokojenia pewnej potrzeby użytkownika).

Aktor jest osobą (lub dowolną inną jednostką), która w jakiś sposób wymienia informacje z systemem, choć pozostaje poza jego zakresem. Jest więc w szerokim znaczeniu użytkownikiem tego systemu, tzn. żąda od systemu wykonania pewnych funkcji i/lub odbiera efekty ich wykonania. Aktor opisuje rolę, a nie konkretną osobę lub jednostkę.

Aktorzy mogą być powiązani ze sobą relacją uogólnienia/uszczegółowienia: w ten sposób zachowanie bardziej ogólnego aktora jest dziedziczone przez aktora bardziej szczegółowego. Ponadto są powiązani z przypadkami użycia, z których korzystają.

Aktor jest reprezentowany na diagramie przypadków użycia w różnoraki sposób: jako sylwetka z nazwą aktora, jako prostokąt ze słowem kluczowym «actor» lub z ikoną.

Przykładami aktorów w systemie bibliotecznym mogą być Bibliotekarz i Czytelnik, reprezentujący fizyczne osoby korzystające z tego systemu, ale także Zegar, który cyklicznie wysyła komunikat powodujący wyszukanie książek o przekroczonym terminie zwrotu.

Przypadek użycia reprezentuje zamkniętą i kompletną funkcjonalność dostępną dla aktora. Zgodnie z definicją, przypadek użycia w UML jest zdefiniowany jako zbiór akcji wykonywanych przez system, które powodują efekt zauważalny dla aktora.

Przypadki użycia zawsze muszą być inicjowane (bezpośrednio lub przez zależności) przez aktora i wykonywane w jego imieniu. Ponadto, przypadek użycia musi dostarczać pewną wartość użytkownikowi oraz musi być kompletny, to znaczy w pełni realizować podaną funkcjonalność oraz dostarczać wyniki aktorowi.

Przypadki użycia komunikują się z aktorami poprzez powiązania, pokazujące, który aktor ma dostęp do podanego przypadku użycia. Ponadto mogą być powiązane pomiędzy sobą: relacją uogólnienia , rozszerzenia i zawierania .

DIAGRAM MASZYNY STANÓW - pokazuje przede wszystkim możliwe stany obiektu oraz przejścia, które powodują zmianę tego stanu. Tym samym tworzony jest cykl życia obiektu, który może być tym istotniejszy w procesie wytwarzania oprogramowania, im więcej jest możliwych stanów obiektu.

Stan - okoliczność lub sytuacja, w jakiej obiekt się znajduje, kiedy spełnia jakiś warunek, wykonuje jakąś czynność lub czeka na jakieś zdarzenie; zwykle obiekt pozostaje w pewnym stanie przez skończony czas.

Maszyna stanowa - określa ciąg stanów przyjmowanych przez obiekt w odpowiedzi na zdarzenia zachodzące w czasie jego życia, a także reakcje obiektu na te zdarzenia; bardzo przydatne, gdy bieżące zachowanie obiektu zależy od jego przeszłości

Stan obiektu trwa w czasie aż do momentu zajścia zdarzenia, które spowoduje zmianę aktualnego stanu na inny;

stan może mieć nazwę, ale często jest charakteryzowany jedynie poprzez wewnętrzne operacje;

Diagramy stanów:

- Są grafami stanów i przejść między nimi

- Opisują reakcje obiektu na otrzymane komunikaty i zdarzenia zewnętrzne

- Modelują zachowanie obiektów danej klasy w oderwaniu od reszty systemu

- Wszystkie obiekty danej klasy znajdujące się w tym samym stanie reagują w jednakowy sposób na otrzymanie tego samego komunikatu lub zdarzenia

Zawierają:

- stany zwykłe(proste) i złożone

- przejścia ze zdarzeniami i akcjami

Najczęściej wykorzystywane do modelowania obiektów reaktywnych (sterowanych zdarzeniami - ang. event-driven)

- zachowanie obiektów reaktywnych jest najlepiej charakteryzowane przez ciąg odpowiedzi na zdarzenia wywołane w jego otoczeniu, przy czym obiekt taki jest zwykle bezczynny do chwili zajścia zdarzenia

- reakcja na konkretne zdarzenie najczęściej zależy od wcześniejszych zdarzeń

- Nacisk kładziony jest na stany stabline, zdarzenia uruchamiające przejścia i akcje wykonywane po każdej zmianie stanu

DIAGRAM INTERAKCJI - w języku UML służy do opisu zależności przy przesyłaniu komunikatów pomiędzy obiektami, czyli zależności w przepływie sterowania pomiędzy obiektami.

Diagram ułatwiający zrozumienie zależności w przepływie sterowania. Metody realizujące to sterowanie są rozproszone w wielu klasach, co powoduje trudności ze zrozumieniem ich wzajemnej zależności i interakcji. Jest to powód sporządzania diagramów interakcji. Służą one do opisu zależności przy przesyłaniu komunikatów dla pewnej grupy obiektów. Często stanowią bardziej precyzyjny opis pojedynczego przypadku użycia. Istnieje wiele wariantów diagramów interakcji o różnych odmianach syntaktycznych. UML wprowadza dwa rodzaje takich diagramów: diagramy sekwencji i diagramy kolaboracji (współpracy).

Do czego służą? Diagramy interakcji są jednym z rodzajów diagramów dynamicznych. Bazują na istniejącym diagramie klas i opisują one sposób w jaki obiekty współpracują ze sobą w celu zrealizowania konkretnej funkcji systemu (przypadku użycia lub scenariusza danego przypadku użycia). Pozwalają na lepsze zrozumienie zdarzeń zachodzących pomiędzy nimi. Ponadto mogą służyć jako model do generowania gotowego kodu programu przez niektóre narzędzia typu CASE.

Na diagramie interakcji przedstawione jest zazwyczaj zachowanie systemu dotyczące jednego przypadku użycia.

Rodzaje diagramów interakcji:

Diagramu sekwencji - (inaczej diagram przebiegu) - przedstawiają zależności czasowe pomiędzy obiektami, służą do modelowania systemów czasu rzeczywistego i złożonych scenariuszy.

Diagramu komunikacji - uwypukla związki strukturalne pomiędzy obiektami wysyłającymi i odbierającymi komunikaty.

Diagramu przeglądu interakcji - Połączenie diagramu sekwencji i diagramu czynności

Można je traktować jak diagramy czynności, w których czynności są zastąpione przez małe diagramy sekwencjil; Interakcje przedstawiają jako sieć czynności

Diagramu czasowego - Interakcje pomiędzy obiektami z naciskiem na czas;Są one przede wszystkim do prezentacji protokołów jako ciągów czasowo uzależnionych komunikatów wymienianych między różnymi obiektami

DIAGRAM KLAS (ang. class diagram ) jest najczęściej używanym diagramem UML. Z reguły zawiera także największą ilość informacji i stosuje największą liczbę symboli.

Na diagramie są prezentowane klasy, ich atrybuty i operacje, oraz powiązania między klasami. Diagram klas przedstawia więc podział odpowiedzialności pomiędzy klasy systemu i rodzaj wymienianych pomiędzy nimi komunikatów. Z uwagi na rodzaj i ilość zawartych na tym diagramie danych jest on najczęściej stosowany do generowania kodu na podstawie modelu.

Klasa jest reprezentowana przez prostokąt z wydzielonymi przedziałami: nazwą, atrybutami i operacjami. W celu zwiększenia czytelności, dowolny z nich można ukryć bądź dodać nowy (np. przechowujący zdarzenia lub wyjątki), choć zwykle są to właśnie trzy przedziały. Tradycyjnie nazwa klasy zaczyna się z dużej litery, jest wytłuszczona, a w przypadku klasy abstrakcyjnej - także pochyła.

Obiekt jest instancją klasy, podobnie jak w przypadku programowania obiektowego. Nazwa obiektu jest umieszczana przed nazwą klasy i oddzielana od niej dwukropkiem.

Cechy klasy reprezentują informację, jaką klasa przechowuje. Mogą zostać zapisane w postaci dwóch, w zasadzie równoważnych notacji: jako atrybuty klasy (umieszczane w przedziale atrybutów) lub jako relacje pomiędzy klasami (zapisywane w postaci linii łączącej klasy). Zwykle pierwsza notacja jest stosowana do typów prostych lub obiektów reprezentujących wartości, natomiast druga do typów złożonych.

Operacje reprezentują usługi, jakie klasa oferuje. Ich realizacje - metody - dostarczają implementacji tych usług.

Zwykle atrybut jest opisywany tylko przez dwa elementy: nazwę i typ. Jednak pełna definicja obejmuje także widoczność atrybutu , definiującą, z jakich miejsc systemu atrybut jest dostępny, krotność , która określa ile obiektów mieści się w atrybucie, dodatkowe ograniczenia nałożone na atrybut, i wartość domyślną . Elementom, których w definicji atrybutu nie podano wartości, przypisywane są wartości domyślne (widoczność prywatna, krotność 1) lub pomija się je.

Podobnie jak w wielu wysokopoziomowych językach programowania, UML posiada 4 poziomy widoczności: publiczny, chroniony, prywatny i publiczny wewnątrz pakietu. Poziomy te zwykle służą do opisywania widoczności cech (atrybutów i asocjacji) oraz operacji, jednak dotyczą także np. klas pakietów etc.

Krotność cechy wskazuje, ile obiektów można, a ile trzeba w niej zawrzeć. Krotność można określać jako ograniczenie dolne i górne, jednak oczywiste lub powtarzające się wartości graniczne można pomijać, np.. zapis 0..* jest skracany do *, a zapis 1..1 do 1.

W praktyce programowania istotna jest krotność 0, 1 i dowolna, natomiast wartości dyskretne są mniej ważne, jako szczególne przypadki wymienionych trzech. W UMLu 2.0 dlatego formalnie usunięto możliwość podawania dowolnych liczb będących ograniczeniami, np. 2..4, jednak z uwagi na czytelność tego zapisu użycie go nie stanowi wielkiego błędu.

Niemal każdy element w UML może posiadać dodatkowe właściwości i ograniczenia, które szczegółowo opisują jego zachowanie i przeznaczenie. Są one zapisywane w nawiasach klamrowych. Atrybuty klasy można oznaczyć jako uporządkowane za pomocą ograniczenia {sorted}, co oznacza, że są one w jakiś sposób (zwykle rosnąco, leksykograficznie) posortowane. Ograniczenie {unique} wymaga, aby obiekty pamiętane wewnątrz atrybutu nie powtarzały się. Właściwość {readOnly} oznacza atrybut, którego wartość jest przeznaczona wyłącznie do odczytu, natomiast {frozen} - którego wartość po zdefiniowaniu nie może być zmieniona.

DIAGRAM KOMPONENTÓW - Diagramy komponentów (component diagram) pokazują podział systemów programowych na mniejsze podsystemy.

Diagramy komponentów przedstawiają fizyczne aspekty systemów obiektowych.

Obrazują uporządkowanie komponentów i zależności między nimi.

Używane do modelowania statycznych aspektów perspektywy implementacyjnej systemu.

Diagramy komponentów są w istocie diagramami klas, w których kładzie się nacisk na komponenty systemu.

Komponent to wymienialny, wykonywalny fragment systemu, z ukrytymi szczegółami implementacyjnymi (np. plik .dll, podprogram)

Komponent udostępnia zestaw interfejsów, może też wymagać pewnych interfejsów do funkcjonowania.

Komponent to wymienny, wykonywalny fragment systemu o hermetyzowanych szczegółach implementacyjnych. Komponenty z natury służą do ponownego wykorzystania poprzez połączenie ich z innymi komponentami, zwykle poprzez ich skonfigurowanie, bez potrzeby rekompilacji.

Funkcjonalność oferowana przez komponent jest dostępna przez interfejsy, które implementuje. Z drugiej strony, komponent może wymagać pewnych interfejsów, które muszą być dostarczone przez inne komponenty.

Diagram komponentów służy do pokazania związków pomiędzy komponentami i interfejsami

Diagram komponentów to rodzaj diagramu wdrożeniowego, który wskazuje organizacje i zależności między komponentami.

Diagramy komponentów przedstawiają:

- zależności pomiędzy komponentami oprogramowania

- komponenty kodu źródłowego

- komponenty kodu binarnego

- koMponenty kodu wykonywalnego

DIAGRAMY STRUKTUR ZŁOŻONYCH, DIAGRAMY SKŁADOWYCH -

Diagram struktur złożonych przedstawia wewnętrzną strukturę obiektu oraz punkty interakcji z innymi obiektami w systemie.

Diagram struktur złożonych (composite structure diagram) pokazuje związki istniejące pomiędzy częściami systemu, które współpracując dostarczają pewnej funkcjonalności.

Wyodrębniony jako osobny diagram w UML 2.0. Wcześniej istniały tylko kooperacje (w diagramie klas).

Diagramy struktur złożonych mogą zawierać:

struktury - zespoły powiązanych elementów

konektory - łącza komunikacyjne (ich typ nie jest określony)

Za pomocą diagramów można prezentować strukturę podsystemu, komponentu, klasy itd.

Aby pokazać funkcje realizowane przez daną strukturę, ale bez podawania szczegółów ich realizacji można korzystać z portów i interfejsów (dostarczanych/wymaganych)

Prezentują klasy wraz z wewnętrzną strukturą ich właściwości

Zarówno diagramy wdrożenia , jak i diagramy składowych są swoistym połączeniem diagramów klas i diagramów obiektów - mogą na nich występować klasy jak i obiekty

DIAGRAMY WDROŻENIA:

Diagramy wdrażania - przedstawiają fizyczny układ systemu

Pokazują, w których częściach sprzętu działają poszczególne fragmenty oprogramowania

Diagramy wdrożenia przedstawiają powiązania między oprogramowaniem (artefaktami) i sprzętem (węzłami). Są stosowane przy modelowaniu dużych systemów.

• Diagram wdrożenia (ang. deployment diagram) odzwierciedla fizyczną strukturę całego systemu, z uwzględnieniem oprogramowania i sprzętu.

• Jednostki oprogramowania są reprezentowane przez artefakty (czyli skompilowane wersje komponentu, który można uruchomić), dane i biblioteki.

• Stronę sprzętową reprezentują węzły, czyli poszczególne urządzenia obliczeniowe, komunikacyjne i przechowujące, powiązane ścieżkami komunikacyjnymi (np. połączeniem TCP/IP).

• Diagramy te są rzadko używane przy modelowaniu mniejszych i średnich systemów, dlatego zwykle ich rola jest ograniczona.

• Ponieważ posługują się zaledwie kilkoma symbolami, dlatego kluczową rolę odgrywają stereotypy nadawane poszczególnym elementom. Pozwalają one doprecyzować znaczenie i funkcję oprogramowania oraz sprzętu.

• Diagramy wdrożenia istotną rolę odgrywają przy wdrażaniu dużych, rozproszonych systemów.

Diagramy wdrożeniowe prezentują:

• konfigurację elementów czasu wykonania

• komponenty sprzętowe

• komponenty oprogramowania

• procesy oraz związane z nimi obiekty

Sprzętowe składowe działającego systemu dzielimy na:

Procesory - reprezentują zasoby obliczeniowe

Posiadają pewną ilość pamięci i zdolność przetwarzania

Mogą wykonywać kod komponentu

Urządzenia - są interfejsem do świata zewnętrznego

Nie mają zdolności przetwarzania (np. monitor, drukarka)

Służą do modelowania infrastruktury sprzętowej (diagramy wdrożenia), pozwalając jednocześnie na zobrazowanie fizycznego rozmieszczenia komponentów na poszczególnych węzłach

DIAGRAM OBIEKTÓW:

przedstawia egzemplarze elementów z diagramu klas;

obrazuje zbiór obiektów i ich związków w danej chwili;

często nazywany jest diagramem instancji (przedstawia instancje klas a nie same klasy);

zawiera na ogół: obiekty, wiązania, notatki, ograniczenia, pakiety, podsystemy, klasy.

Na diagramie obiektów przedstawia się obiekty, czyli konkretne instancje klas i związki między nimi. Diagram ten wyobraża statyczny rzut pewnych egzemplarzy elementów występujących na diagramie klas. Podobnie jak diagram klas, odnosi się do statycznych aspektów perspektywy projektowej lub procesowej. Korzystając z niego bierze się jednak pod uwagę przypadki rzeczywiste lub prototypowe.

• Diagram obiektów jest wizualizacją hipotetycznego stanu systemu podczas jego działania. Służy do tworzenia przykładów pomagających zrozumieć diagram klas a przede wszystkim powiązań w nim występujących.

• Z punktu widzenia notacji diagramy obiektów używają elementów zapożyczonych z diagramów klas, chociaż często używają prostszej notacji.

• Skupiają się na obiektach a nie na związkach pomiędzy klasami. Większość z nich używa wyłącznie obiektów i asocjacji.

DIAGRAMY PAKIETÓW:

Pakiet to pojęcie określające część systemu (np. zbiór klas lub innych bytów UML) pozwalających na grupowanie w jednostki wyższego pozimu

Diagram pakietów to diagram pokazujący pakiety i zależności między nimi

Pakiet stanowi zgrupowanie elementów modelu logicznego

Komponent jest zgrupowaniem elementów modelu implementacyjnego.

Cele diagramu pakietów:

Pokazanie rozbicia dużego systemu na mniejsze

Pokazanie zależności między elementami systemu

Ułatwienie testowania

Pakiet może być abstrakcyjny

Diagramy pakietów (ang. package diagrams) służą do modelowania fizycznego i logicznego podziału systemu. Pakiety są elementem strukturalizującym elementy UML i służą do grupowania ich według dowolnego kryterium. W pakiecie można umieścić praktycznie dowolne elementy: klasy, komponenty, przypadki użycia, a także inne pakiety. W ten sposób przedstawiają one drzewiastą strukturę elementów modelu.

Pakiety doskonale nadają się do wizualizacji podstawowych zależności pomiędzy częściami systemu, dzięki czemu łatwo ocenić jakość i stopień powiązań pomiędzy nimi. Dobra struktura pakietów, w której zależności są jasno uporządkowane oraz nie występują (lub występują tylko na niskim poziomie) zależności cykliczne, wspiera późniejszą rozbudowę systemu. W szczególności przydają się w dużych aplikacjach, podzielonych na wiele podsystemów, ponieważ w prosty sposób obrazują podstawowe zależności pomiędzy nimi.

Pakiet tworzy także jednostkę hermetyzacji: elementy z pakietu odwołują się do elementów zewnętrznych posługując się ich pełnymi kwalifikowanymi (zawierającymi nazwy pakietów) nazwami, zgodnie z ich zakresem widoczności, natomiast wewnątrz pakietu elementy mogą odwoływać się do siebie bezpośrednio.

Elementy wewnątrz pakietu mogą mieć jeden z dwóch poziomów widoczności: prywatny lub publiczny. Elementy publiczne są widziane i mogą być użyte poza własnym pakietem, natomiast prywatne - nie. Aby elementy pakietu mogły odwołać się do elementów prywatnych z innego pakietu, muszą go importować. Oznacza to, że elementy te stają się dla importującego pakietu widoczne. Import pakietu oznaczany jest zależnością ze słowem kluczowym << import >>.

W miarę wzrostu wielkości modelowanego systemu, rośnie liczba wykorzystywanych elementów (klas, interfejsów, komponentów...)

Można grupować modelowane byty w pakietach.

Dobrze zaprojektowane pakiety składają się z podobnych znaczeniowo i razem zmieniających się bytów. Są luźno powiązane ze sobą, ale silnie spójne wewnętrznie.

Dostęp do zawartości pakietów jest kontrolowany

Reprezentacja graficzna pakietu (Nazwa pakietu (może teżbyć napisana na zakładce):

---