DIAGRAMY PRZYPADKÓW UŻYCIA Przypadki użycia były w sposób intuicyjny stosowane w tradycyjnym projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk obiektowych. Zasługą Jacobsona jest zarówno wyodrębnienie przypadków użycia jako metody projektowania, jak i stworzenie metodyki i notacji graficznej dla tego paradygmatu. Jak często bywa z powszechnie stosowanymi, lecz nie nazwanymi rzeczami, kariera przypadków użycia w literaturze z zakresu projektowania systemów informatycznych (SI) zaczęła się od wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako swego rodzaju paradygmatu projektowania SI. Przypadek użycia jest to pewna nazwana, dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcjonalność systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Jakkolwiek w tym stwierdzeniu można podejrzewać banał, rzecz tak oczywistą, że nie warto o niej mówić, okazuje się, że dla dużych systemów o wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomnieć o detalach technicznych (nawet abstrahować od architektury) i skoncentrować się na logice systemu. Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść technokratycznych, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami, a systemem komputerowym. Reasumując przypadek użycia można definiować na wiele sposobów. Oto kilka definicji: Przypadek użycia to wycinek funkcjonalności, którą system musi realizować, aby spełnić wymagania Przypadek użycia jest zbiorem ciągów akcji wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Przypadek użycia to zbiór scenariuszy powiązanych wspólnym celem użytkownika. Przez scenariusz rozumiany jest tu ciąg kroków opisujących interakcje między użytkownikiem, a systemem Podejście przypadków użycia ma przede wszystkim na względzie określenie wymagań funkcjonalnych na projektowany system. Celem tej metody jest: Identyfikacja wymagań funkcjonalnych o Każdy przypadek użycia powinien opisywać realizację jakiegoś celu biznesowego opisanego z punktu widzenia aktora używającego system o Zbiór przypadków użycia stanowi podstawę do umowy między klientem, a dostawcą
o Przypadki użycia ułatwiają zadanie ustalenia priorytetów dla wymagań funkcjonalnych Odpowiedź na pytanie, co system ma robić bez określania sposobu realizacji Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu Określenie granic systemu Ustalenie praw dostępu do zasobów Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu Przygotowanie podstaw do szczegółowej analizy i projektowania o Podstawa do identyfikacji klas i obiektów o Określenie odpowiedzialności i współpracy obiektów o Definicja przepływu komunikatów miedzy obiektami Weryfikacja poprawności i kompletności projektu Dostarczenie podstaw do sporządzenie planu testów systemu Pomiędzy przypadkami użycia można wyróżnić przynajmniej trzy podstawowe relacje: Zawieranie o Pozwala na współdzielenie fragmentu funkcjonalności pomiędzy kilkoma przypadkami użycia. Do relacji zawierania dochodzi wówczas, gdy kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której nie warto wciąż kopiować z jednego przypadku użycia do drugiego. Rozszerzanie o Pozwala na warunkowe rozszerzenie funkcjonalności przypadku użycia osadzone w punkcie rozszerzenia. Rozszerzenie przypadku użycia może więc wzbogacić go o dodatkowe zachowanie, ale w takiej sytuacji podstawowy przypadek użycia musi określić pewne punkty rozszerzenia, a rozszerzający przypadek użycia może dodać nowe zachowanie tylko w tych punktach. Przypadek użycia może mieć wiele punktów rozszerzeń, a rozszerzający przypadek użycia może rozszerzać podstawowy przypadek użycia w kilku z tych punktów. Relacja rozszerzania służy do opisywania opcjonalnego przepływu zdarzeń i pozwala na minimalizację liczby zmian wprowadzanych do podstawowego przypadku użycia. Uogólnienie o Pozwala na zilustrowanie różnych wariantów realizacji tego samego przypadku użycia. W istocie jest bardzo podobne do rozszerzania, jest jednak mniej formalne. Relacji uogólnienia używa się wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest nieco obszerniejszy. Specjalizowany przypadek użycia może przesłonić dowolną część podstawowego przypadku użycia, ale zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika, co podstawowy przypadek użycia. Relacja uogólnianie może być traktowana
jako sposób na przedstawienie szczególnej realizacji uogólnionego przypadku użycia. Diagramy przypadków użycia są bardzo proste i głównie dzięki temu tak użyteczne.
DIAGRAMY KLAS Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemów informatycznych. Opisuje wyróżnione w systemie klasy obiektów i statyczne powiązania między nimi. Zawiera on również takie elementy jak atrybuty i operacje klas oraz ograniczenia nakładane na klasy obiektów i ich powiązania. Modelując statyczne aspekty perspektywy projektowej, diagramów klas używa się do: Modelowanie słownictwa systemu. Zadanie to polega między innymi na podejmowaniu decyzji, które abstrakcje są częścią rozważanego systemu, a które nie i jakie zobowiązania ma każda z tych abstrakcji. Modelowanie prostych kooperacji. Kooperacja jest to zestaw klas, interfejsów i innych bytów istniejących celem realizacji pewnego zespołowego zachowania wymagającego współpracy wszystkich elementów. Nie należy skupiać się nad jedną klasą, lecz nad zbiorem współpracujących ze sobą klas, by zrozumieć, o co chodzi. W tym wypadku diagramy klas wykorzystuje się do zobrazowania i określenia tego zbioru klas i związków między nimi. Modelowanie schematu logicznej bazy danych. Przez schemat rozumiany jest plan projektu koncepcyjnego bazy danych. W wielu dziedzinach zachodzi potrzeba trwałego przechowywania informacji w bazach danych. W tym wypadku diagram klas wykorzystuje się do modelowania schematów takich baz danych. Klasa jest opisem zbioru obiektów, które mają takie same: Atrybuty opisują stan o Najczęściej typy proste lub biblioteczne o Nie posiadają własnych reguł biznesowych o Ich wartości są istotne dla obiektów klasy Operacje opisują zachowanie o Usługi oferowane przez każdy obiekt klasy o Zwykle powodują zmianę stanu obiektu o Dzielą się na zapytania i polecenia Związki uogólnienie, realizacja, zależność, asocjacja, agregacja, kompozycja o Umożliwiają obrazowanie faktu, że zachowanie jednej klasy zależy od zachowania innej klasy o Powalają na unikanie antywzorów (np. BLOB ) Znaczenie Klasa realizuje jeden bądź wiele interfejsów. Interfejs definiuje zewnętrznie obserwowane zachowanie klasy lub komponentu, określając zbiór deklaracji operacji, ale nigdy sposobu implementacji.
DIAGRAMY KOMPONENTÓW Komponenty, w odróżnieniu od bytów koncepcyjnych jakimi są np. diagramy klas, są elementami oprogramowania istniejącymi w systemie komputerowym i będącymi fizyczną realizacją zamysłu projektanta oprogramowania, czyli składnikiem konkretnego systemu programowego. Należy tu uchwycić subtelną granicę rozciągłości definicji klasy w stosunku do definicji komponentu, tzn. najważniejszym wyróżnikiem odmienności tych dwóch pojęć jest to, iż klasa jest abstrakcyjnym przedstawieniem zbioru atrybutów i operacji, podczas gdy komponent jest fizyczną częścią systemu. Analizując zagadnienie projektowania realnych fragmentów oprogramowania (komponentów) można dojść do wniosku, że szczególny nacisk powinien zostać położony na możliwość wyizolowania komponentu i jego wielokrotnego użycia. Zadanie to ułatwiają dobrze zdefiniowane interfejsy, które są jedyną drogą przez którą dostępne są operacje komponentu - zupełnie jak w przypadku klas - relację tego typu nazywamy realizacją. Nie można pominąć znaczenia interfejsu jako swego rodzaju "okna na świat" dla komponentu, co warunkuje możliwości jego wymiany i wielokrotnego wykorzystania. Należy w tym miejscu dodać, że w specyfikacji UML 2.0 wyróżnione zostały dwa typy interfejsów. Jeżeli komponent udostępnia jakieś usługi w postaci interfejsu to mówimy wówczas o tzw. interfejsie dostarczanym, udostępnianym lub eksportowanym (ang. provided interface). Może jednak zajść przypadek, że komponent, aby w pełni realizować swoje usługi, potrzebuje skorzystać z usług innych komponentów, co obrazuje się za pomocą interfejsu wymaganego, importowanym (ang. required interface). Wyróżniamy 3 podstawowe rodzaje komponentów: wdrożenia - są podstawą oprogramowania wykonywalnego o COM+, JavaBeans, EJB, biblioteki DLL, pliki wykonywalne EXE,... procesu wytwórczego - komponenty będące artefaktami powstałymi w procesie wytwarzania, na ich podstawie generuje się komponenty wdrożenia o schemat logiczny bazy danych, skrypty SQL, pliki z kodem źródłowym, komponenty wykonania - tworzone jako rezultat działania systemu o wydruki, raporty, W końcu dochodzimy do definicji diagramu komponentów, który zawiera komponenty, interfejsy oraz ich wzajemne związki. Elementy te są ze sobą luźno powiązane najczęściej za pomocą zależności i realizacji.
DIAGRAMY WDROŻENIA Diagram wdrożenia, obok diagramu komponentów to jeden z dwóch rodzajów diagramów przedstawiających fizyczne aspekty systemów. Jego zadaniem jest zobrazowanie konfiguracji węzłów w czasie wykonania, na których rozmieszczone będą komponenty. Komponenty reprezentują fizyczne (programowe ang. software), wymienne części systemu, które realizują elementy logiczne, podczas gdy węzły to fizyczne (sprzętowe ang. hardware) składnik systemu na których wdrożone zostają komponenty. Najczęściej mamy do czynienia z sytuacją w której diagramy komponentów umieszczane są na diagramach wdrożenia, aby pokazać, które komponenty działają na których węzłach. Węzły dzielone są na: procesory reprezentują zasoby obliczeniowe o posiadają pewną ilość pamięci i zdolność przetwarzania, o mogą wykonywać kod komponentu urządzenia są interfejsem do świata zewnętrznego o nie mają zdolności przetwarzania (np. monitor, drukarka) Diagramy wdrożenia są szczególnie przydatne dla projektantów systemów, których sposób funkcjonowania zależy równie sileni od oprogramowaniu wchodzącym w skład systemu, jak i sprzętu na którym to oprogramowanie ma działać. Pozwalają na zobrazowanie infrastruktury wymaganej przez system. Pomiędzy węzłami występują połączenia (ang. connection), które najczęściej opatrzone są różnymi stereotypami opisującymi ich charakter. Można wyróżnić trzy zasadnicze typy systemów, przy modelowani których warto wykorzystać diagramy wdrożenia: systemy wbudowane, systemy typu klient-serwer oraz systemy rozproszone. Istotna nowością, która została wprowadzona w specyfikacji UML 2.0 jest dodanie elementu będącego specyfikacją wdrożenia. Element ten odpowiada za opis parametrów potrzebnych do wdrożenia komponentu na danym węźle, co ma na celu parametryzację relacji pomiędzy różnymi programowymi i sprzętowymi technologiami. Specyfikacja wdrożenia jest obrazowana za pomocą stereotypu <<deploymentspecyfication>> Ciekawym elementem jest również tzw. środowisko wykonania. Element ten reprezentuje wybrany rodzaj platformy i jest obrazowany za pomocą stereotypu <<ExecutionEnvironment>>
DIAGRAMY OBIEKTÓW Diagramy obiektów przedstawiają hierarchię obiektów i ich wzajemne powiązania w danej chwili. Jako że przedstawiają instancje klas, a nie same klasy - nazywane są też czasem diagramami instancji. Na diagramach obiektów umieszczamy specyfikacje instancji, a nie same instancje. Rozwiązanie takie umożliwia nie nadawanie wartości obowiązkowym atrybutom, lub też obrazowanie specyfikacji instancji klas abstrakcyjnych. Diagramy obiektów podobne są do diagramów komunikacji, jednakże te pierwsze służą do zobrazowania struktury instancji, diagramy komunikacji natomiast do pokazania ich zachowań.
DAIGRAMY STRUKTUR ZŁOŻONYCH Diagramy struktur złożonych służą do hierarchicznego opisywania skomplikowanych fragmentów oprogramowania. Pozwala to na zajęcie się skomplikowanym elementem i podzielenie go na części. Struktury złożone są podobne do pakietów. Aby uświadomić sobie podstawową różnicę najlepiej myśleć o pakietach jako o sposobie grupowania elementów w czasie kompilacji, podczas gdy struktury złożone grupują elementy w czasie wykonania programu. Diagramy struktury swoja notację i zakres stosowania wywodzą głównie z modeli systemów czasu rzeczywistego, gdzie stosowane jest pojęcie tzw. kapsuły, która reprezentuje wyraźnie wydzielony i hermetyczny wątek sterowania systemu. Całkowita izolacja kapsuła (w obu kierunkach) od jej otoczenia możliwa jest dzięki portom, które pełnia rolę obiektów granicznych (interfejsów). Interesujący jest fakt, że diagramy struktury mogą obrazować aspekty statyczny i dynamiczny modelowanego systemów, co stanowi o ich osobliwości. Najczęściej mamy do czynienia z przypadkiem, w którym diagramy struktury ilustrują dekompozycję wskazującą z jakich części składa się kapsuła i w jakie interfejsy jest ona zaopatrzona. Istnieje jednak druga forma diagramów struktury umożliwiająca przedstawienie komunikacji, jaka zachodzi pomiędzy wewnętrznymi elementami kapsuły. Taka forma prezentacji diagramów struktury została nazwana w UML 2.0 diagramem współpracy. Należy pamiętać, że gdy diagram struktury przyjmuje pierwszą formę to można użyć na nim portów i interfejsów. Prezentując natomiast zbiór współpracujących ze sobą elementów składowych kapsuły nie można wykorzystywać portów i interfejsów, ale należy skorzystać ze stereotypowych zależności: <<role binding>>, <<represents>>, <<occurrence>> Ponieważ struktury złożone są nowością, to trudno stwierdzić, jak przydatne okażą się w praktyce.
DIAGRAMY PAKIETÓW Pakiet jest konstrukcją pozwalającą organizować elementy modelu np. klasy, w logiczne grupy. Natomiast diagram pakietów to diagram składający się z pakietów i zależności między nimi. Pakiety z reguły tworzy się, aby: W przejrzysty sposób zobrazować zależności pomiędzy poszczególnymi elementami modelu. Efektywniej organizować kod źródłowy. Zaznaczyć podobieństwa i różnice pomiędzy poszczególnych elementów modelu. Na diagramie pakietów wszelkie elementy modelu (klasy, interfejsy, kooperacje, komponenty, ) grupowane są w pakiety i/lub podpakiety zgodnie z poziomami zawierania. Warto tworzyć tego typu diagramy dążąc do tego, aby elementy modelu połączone relacjami asocjacji, agregacji, czy to kompozycji umieszczone były w jednym pakiecie. Z reguły naturalnym jest, by w pakiecie umieszczać elementy modelu, które w jakikolwiek sposób od siebie zależą. Diagramy pakietów można także stosować w celu grupowania przypadków użycia. Ogólne zasady tworzenia diagramów pakietów są bardzo proste: Zawsze nadawaj pakietom proste, opisowe nazwy Stosuj pakiety do upraszczania struktury diagramów Stosuj stereotypy by zaznaczyć warstwy architektury programu Zależności między pakietami powinny odzwierciedlać faktyczne wewnętrzne relacje w programie Pakiety powinna charakteryzować wysoka zwartość i niskie sprzężenie.
DIAGRAMY SEKWENCJI Diagram sekwencji (przebiegu) jest jednym z diagramów interakcji. Diagramy interakcji odnoszą się do modelowania dynamicznych aspektów systemu i służy do opisu współpracy pomiędzy grupą obiektów. Na diagramach sekwencji uwzględnia się konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Elementy te są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagram sekwencji główny nacisk kładzie na uwypuklenie kolejność przesyłania komunikatów w czasie. Diagramy sekwencji stosuje się, aby spojrzeć na zachowanie się kilku obiektów w ramach jednego przypadku użycia systemu. Są użyteczne do przedstawiania współpracy obiektów, ale nie umożliwiają ścisłej definicji zachowania. Reasumując diagramy sekwencji: Przedstawiają interakcje pomiędzy obiektami (w UML 2.0 tzw. uczestnikami interakcji), przy czym największy nacisk kładą na zależności czasowe. Stosowane są zawsze, gdy kolejność wywołań oraz ograniczenia czasowe są istotne Nadają się do modelowania: o Systemów czasu rzeczywistego o Przetwarzania współbieżnego o Złożonych scenariuszy Nie prezentują związków strukturalnych miedzy współdziałającymi obiektami (uczestnikami) Pozwalają na zaprezentowanie różnych typów interakcji: o Synchroniczna o Asynchroniczna o Notacja UML 2.0 wprowadziła do diagramów sekwencji szereg nowości, które bez wątpienia ułatwiają prezentację złożonych scenariuszy wybranych przypadków użycia. Częstym problemem towarzyszącym diagramom sekwencji była trudność z przedstawieniem zachowania warunkowego i pętli. Rozwiązaniem okazało się wprowadzenie ramek interakcji, które służą do wyróżnienia fragmentu diagramu sekwencji. Każda taka ramka ma operator (stereotyp interakcji), a każdej wydzielonej części ramki może towarzyszyć warunek, co pozwala na wizualizowanie różnych wariantów złożonego scenariusza. Najczęściej stosowane stereotypy interakcji: alt (alternatywa) zostaje wykonany tylko ta część ramki, której warunek jest prawdziwy.
opt (opcja) fragment zostaje wykonany tylko wówczas, gdy zawarty w nim warunek jest prawdziwy, czyli odpowiednik operatora alt z jednym wejściem. par (współbieżność) każda część ramki interakcji uruchamiana jest równolegle. loop (pętla) ramka interakcji może być wykonana kilka razy, a warunek określa podstawę interakcji. region (obszar krytyczny) ramka interakcji może mieć tylko jeden wątek uruchomiony w dane chwili. neg (negacja) ramka przedstawia niepoprawna interakcję. ref (referencja) ramka odwołuje się do interakcji zdefiniowanej na innym diagramie. Ramka jest rysowana tak, aby przykrywać linie czasu obiektów biorących udział w interakcji. Można zdefiniować parametry wejściowe i wartości zwracaną. sd (diagram sekwencji) używany do otaczania ramką całego diagramu sekwencji, w miarę potrzeb.
DIAGRAMY KOMUNIKACJI Diagram komunikacji jest jednym z diagramów interakcji. Diagramy interakcji odnoszą się do modelowania dynamicznych aspektów systemu i służy do opisu współpracy pomiędzy grupy obiektów. Na diagramach komunikacji uwzględnia się konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Elementy te są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagram komunikacji kładzie nacisk na związki strukturalne między obiektami (w UML 2.0 tzw. uczestnikami) biorącymi udział w interakcji oraz komunikaty przesyłane między nimi. Jest wygodniejszy od diagramów sekwencji do przedstawienia złożonych iteracji i rozgałęzień. W swojej idei diagramy komunikacji są podobne do diagramów sekwencji. Ich głównym celem jest więc przedstawienie przepływu komunikatów pomiędzy obiektami. Diagramy komunikacji uwzględniają jednak dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki, atrybuty i operacje (jest to nazywane kontekstem współpracy ), oraz kolejność komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania. Diagram komunikacji może być rozrysowany dla pewnych typów obiektów, dla pewnych operacji lub pewnych przypadków użycia. W odróżnieniu od diagramów sekwencji wymiar czasu nie jest bezpośrednio odwzorowany i nie ma on takiego znaczenia. Natomiast odwzorowane są powiązania pomiędzy obiektami (prezentujące pewną część powiązań z diagramu klas). Diagram sekwencji i komunikacji są semantycznie równoważne tzn., że przekazują tę samą informację. Istnieje możliwość przekształcenia diagramu sekwencji w diagram komunikacji i odwrotnie bez utraty informacji.
DIAGRAMY CZYNNOŚCI Diagramy czynności to kolejny diagram służący do modelowania dynamicznych aspektów systemu. Diagramy te w zasadzie są schematami blokowymi, które przedstawiają przepływ sterowania z czynności do czynności. Obrazują one sekwencyjne bądź to równoległe/współbieżne kroki procesu. Stanowią uogólnioną wersję diagramów stanów, a ich podstawowym zadaniem nie jest analiza stanów obiektu, ale modelowanie przetwarzania (przepływu zadań). Stany diagramu czynności odpowiadają stanom wyróżnianym w trakcie przetwarzania, a nie stanom obiektów. Czynność może być interpretowana jako zadanie do wykonania przez człowieka lub komputer ale również jako odpowiedzialność, operacja czy metoda klasy, a więc diagram może być tworzony na różnych poziomach szczegółowości. Przejścia pomiędzy stanami (czynnościami) nie są związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania specyficznego dla danej aktywności. Diagramy czynności możemy wykorzystać na bardzo wiele sposobów. Są szczególnie przydatne przy tworzeniu SI i to nie tyko w podejściu obiektowym. Tak więc: Umożliwiając zrozumienie procesów biznesowych Doskonale nadają się do modelowania przepływu zdań i w opisie procesów z dużą liczbą równoległych czynności Wykorzystywane są, jako wygodnym sposobem analizy przypadków użycia Dają możliwość opisu czynności warunkowych i współbieżnych o Proces warunkowy jest przedstawiany za pomocą rozgałęzienia (ang. branch) i scalenia (ang. marge) o Proces współbieżnych jest przedstawiany za pomocą rozwidlenia (ang. fork) i złączenia (ang. join) Określają sposób realizacji rozpatrywanego działania opisując podstawowe reguły porządkujące (szeregujące) czynności Pozwalają na zobrazowanie współdziałania obiektów oraz określenie obiektów odpowiedzialnych za wykonanie danej czynności na wysokim poziomie abstrakcji za pomocą tzw. torów pływackich (ang. swimlines). W celu uszczegółowienia należy stosować diagramy interakcji Mogą być stosowane do opisu algorytmów sekwencyjnych, równoległych i współbieżnych Zmiany wprowadzone w notacji UML 2.0, a dotyczące diagramów czynności sięgają bardzo daleko. Pierwszą widoczną zmianą jest umożliwienie zastosowania torów (partycji) zarówno pionowych jak i poziomych (powstaje dwuwymiarowa siatka). Pozwala to prezentować nie tylko obiekty odpowiedzialne za wykonanie danej czynności, ale grupować czynności w większe zbiory i przypisywać im zbiorcze nazwy lub miejsca realizacji. Inna nowością jest wprowadzenie możliwości zakończenia realizacji scenariusza, w dowolnym miejscu jeżeli zajdzie określony warunek. Dopracowano
również sposób przesyłania obiektów pomiędzy czynnościami wprowadzając pojęcie żetonu (ang. token) i wtyku (ang. pin) wykorzystywanych do przekazywania parametrów wejściowych i wyjściowych pomiędzy czynnościami. Idea ta pochodzi z sieci Petriego. Diagramy czynności wykorzystywane są do dynamicznego modelowania systemów. W szczególności stosowane są do modelowania przepływu zadań i opisu algorytmów. Mocną stroną tych diagramów jest to, że zachęcają do stosowania procesów współbieżnych tam gdzie to tylko możliwe.
DIAGRAMY MASZYNY STANÓW Diagramy maszyny stanów, nazywane również diagramami stanów, są znaną techniką opisu zachowania się systemu. Wykorzystywane są więc do modelowania dynamicznych aspektów systemu. W technice obiektowej diagramy te wykorzystuje się do zobrazowania możliwych stanów obiektu oraz przejść, które powodują zmianę stanu obiektu. Istotną zaletą diagramów maszyny stanów jest możliwość modelowania zachowania obiektów danej klasy w oderwaniu od reszty systemu. Są szczególnie użyteczne do modelowania historii życia obiektu. Przedstawiają reakcje obiektów na otrzymane zdarzenia. Nadaje się więc do opisu obiektów reaktywnych oraz projektowania systemów interakcyjnych. Formalnie diagram maszyny stanów jest grafem skierowanym, którego wierzchołki stanowią stany obiektu, a łuki opisują przejścia między stanami. Przejście jest odpowiedzią obiektu na jakieś zdarzenie. Akcje są związane z przejściami i traktuje się je jako procesy szybkie i nieprzerywalne (atomowe). Ze stanami związane są czynności, które mogą trwać dłużej i mogą zostać przerwane przez zdarzenie. Diagramy maszyny stanów pozwalają również na wizualizowanie tzw. stanów złożonych. Stan złożony powstaje w efekcie zagnieżdżania stanów i w związku z tym może być dokomponowany na stany bardziej proste. Dekompozycja jest rodzajem specjalizacji. Każdy z podstanów musi dziedziczyć przejścia nadstanu. Tylko jeden z podstanów może być aktywny w danym momencie. Diagramy maszyny stanów radzą sobie również w wypadku, gdy obiekt ma pewne zbiory niezależnych zachowań czyli może znajdować się w kilku stanach równocześnie (tzw. stany współbieżne). Jeśli jednak dla jednego obiektu jest klika skomplikowanych diagramów stanów współbieżnych, to dobrom praktyką jest próba rozbicia tego obiektu na kilka prostszych. Reasumując elementy diagramów stanów to: Stany mogą mieć nazwy, a identyfikowane są na trzy sposoby: o Wartości atrybutów obiektu o Czas, gdy obiekt oczekuje na nadejście jakiegoś zdarzenia event zdarzenie(a:t)/[warunek]/akcja o Czas, w którym obiekt wykonuje jakieś czynności do/czynność1/czynność2/ Zdarzenia bodźce, które mogą uruchomić przejścia pomiędzy stanami o Wolanie operacja(a:t), synchroniczne wywołanie żądania, gdzie obiekt wołający czeka na wynik o Zmiana when(wyrażenie), ciągłe czekania na spełnienie warunku o Sygnał sygnał(a:t), asynchroniczna komunikacja jednokierunkowa
o Czas after(czas), uzależnienie od czasu określanego bezwzględnie lub względnie Przejścia wskazują, że obiekt przejdzie z jednego stanu do drugiego, o ile zajdzie określone zdarzenie i będą spełnione warunki o zdarzenie(a:t)[warunek]/akcja przejścia zewnętrzne i wewnętrzne o [warunek]/akcja przejście automatyczne o entry/akcja1we/akcja2we/ wykonanie akcji podczas wejścia do stanu o exit/akcja1wy/akcja2wy/ wykonanie akcji podczas wyjścia ze stanu
DIAGRAMY PRZEGLĄDU INTERAKCJI Diagramy przeglądu interakcji są krzyżówką diagramów czynności i diagramów sekwencji i/lub komunikacji. Należy je traktować tak, jak diagramy czynności, w których czynności (aktywności) są zastąpione przez diagramy sekwencji. Istnieje możliwość stosowania dwóch rodzajów elementów interakcyjnych: prostokąty posiadające nazwę diagramu sekwencji i stanowiące jego referencję, zaznaczaną słowem kluczowym REF, które znajduje się w lewym górnym rogu diagramy sekwencji bądź komunikacji, które mogą być bezpośrednio zagnieżdżane w diagramach przeglądu interakcji Ponieważ diagramy przeglądu interakcji są nowością, to trudno stwierdzić, jak przydatne okażą się w praktyce.
DIAGRAMY PRZEBIEGÓW CZASOWYCH Diagram przebiegów czasowych jest nowym diagramem interakcji, w którym nacisk kładzie się na ograniczenia czasowe albo dla pojedynczego obiektu, albo, co bardziej pożyteczne dla całej grupy obiektów. Na jego pojawienie się czekali przede wszystkim projektanci systemów czasu rzeczywistego i aplikacji, których działanie jest uzależnione od współpracy z urządzeniami wejścia/wyjścia. Diagram przebiegów czasowych obrazuje zachowanie obiektu z naciskiem na dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianą lub sam wykonuje jakieś działanie. Diagramy czasowe przydają się do obrazowania ograniczeń czasowych występujących między zmianami stanów różnych obiektów. Są szczególnie przyjazne dla inżynierów zajmujących się projektowaniem urządzeń.
Źródła: Martin Fowler, UML w kropelce wersja 2.0, LTP, Warszawa 2005 Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania obiektowego, Helion, Gliwice 2005 http://www.holub.com/goodies/uml/ http://www.agilemodeling.com/essays/umldiagrams.htm