Wykorzystanie technik i metod obiektowych w projektowaniu SI

Wykorzystanie technik i metod obiektowych w projektowaniu SI Halina Tańska

Istota problemu Historia ludzkości pokazuje, że podejście metodyczne jest podstawą osiągania sukcesu. Można przywołać wielkie starożytne czy średniowieczne projekty budowlane, operacje wojskowe i mnóstwo innych podjętych przedsięwzięć. Obecnie wykorzystywanie metodyk w realizowaniu większości działań staje się wymogiem. Jest to związane z krótszymi cyklami realizacyjnymi produktów oraz ciągle rosnącą konkurencją. Zwiększające się tempo jest ściśle związane ze zmianą, a projekty z racji swoich cech, pozwalają na utrzymanie tempa i elastyczne dostosowywanie się do zmian środowiska.

Zastosowanie metodyk obiektowych, języka UML w podejściu obiektowym diagramów wraz z przykładami: § § § § diagram przypadków użycia, diagram klas, diagram obiektów, diagram komponentów, diagram przebiegu, diagram kooperacji, diagram stanów, diagram czynności, proces RUP, zalety i wady podejścia obiektowego.

Wprowadzenie Podczas wytwarzania gotowego oprogramowania należy uwzględnić dwa różne punkty widzenia. Z jednej strony punkt widzenia zamawiających, którzy mają pewne wymagania w stosunku do systemu. Z drugiej strony mamy programistów, którzy wiedzą, jak konstruować systemy. Zamawiający znają dziedzinę problemu i potrafią o niej opowiadać za pomocą specjalistycznego słownictwa. Nie są to jednak osoby skłonne do czytania, a tym bardziej tworzenia technicznych opisów systemu. Zamawiający chcą opisać system w sposób jak najprostszy i jak najbardziej zrozumiały w kontekście swoich codziennych obowiązków. Wynika to oczywiście z tego, że system powinien im pomagać w pracy, którą wykonują.

Wprowadzenie Z drugiej strony programiści tworzą system z bardzo precyzyjnych konstrukcji odpowiedniego języka programowania. Są oni najczęściej dokładnie zorientowani w szczegółach platformy sprzętowej lub programowej, czy też w niuansach określonej biblioteki kodu. Nie są natomiast ekspertami w dziedzinie, dla której tworzą system. Ich słownictwo jest zasadniczo różne od słownictwa zamawiających. Wymagają zatem bardzo dokładnego opisu sposobu konstrukcji systemu. W rzeczywistości przecież gotowy system powinien być jak najwierniejszym modelem środowiska, którego dotyczy.

Problem Zarówno zamawiający, jak i programiści muszą panować nad systemem, który zwykle składa się z tysięcy różnych wymagań. Jak zatem zapanować nad złożonością problemu? Doskonałym rozwiązaniem okazuje się modelowanie za pomocą technik obiektowych. Elementem, który w modelowaniu obiektowym pozwala pogodzić język użytkownika z językiem programisty oraz pokonać problem złożoności systemu jest obiekt. Obiekty znajdujące się w środowisku ustalają wspólny język w zespole odpowiedzialnym za powstanie systemu oprogramowania. Odpowiadają pojęciom z modelowanej dziedziny problemu oraz są podstawą implementacji realizowanego systemu.

Modelowanie obiektowe Na bazie obiektów powstają obiektowe modele, czyli kopie rzeczywistych systemów. Modelowanie obiektowe polega zatem na: § znajdowaniu obiektów w otoczeniu § opisywaniu struktury i dynamiki działania obiektów, § klasyfikacji obiektów, § opisywaniu struktury powiązań klas obiektów, § opisywaniu dynamiki współpracy obiektów podczas funkcjonowania systemu. Modelowanie obiektowe polega na rysowaniu diagramów opisujących strukturę i dynamikę systemu składającego się z obiektów.

Obiekt w rozumieniu modelowania obiektowego może być opisany za pomocą trzech elementów: tożsamości, stanu i zachowania. Każdy obiekt ma zatem indywidualną tożsamość odróżniającą go od innych obiektów. Obiekty zawierają również elementarne składniki o zmieniających się wartościach, które określają ich stan. Potrafią też zachowywać się w odpowiedni sposób w różnych sytuacjach – wykonują określone usługi na rzecz innych obiektów.

Obiekt • Stan obiektu to zbiór jego cech charakterystycznych. Każdy obiekt ma przypisany zbiór właściwości, które go charakteryzują. Są one nierozerwalnie związane z danym obiektem i tak naprawdę są one również obiektami, które w całości kontroluje obiekt główny. W czasie swojego życia obiekt ma zawsze ten sam zestaw właściwości, jednak mogą one przyjmować różne wartości, przez co wyznaczają stan obiektu w danym momencie.

Obiekt • Tożsamość wyróżnia obiekt pośród innych obiektów jako osobną jednostkę. Można ją określić jako wyróżnioną cechę obiektu, która pozostaje niezmienna przez cały czas życia tego obiektu. Wartość tej cechy powinna być unikalna wśród wszystkich obiektów, które otaczają obiekt. Jednocześnie może ona stanowić elementu stanu obiektu. Warto też podkreślić, że oczywiście możliwe jest rozróżnienie tożsamości obiektów za pomocą ich stanu (np. stwierdzając, jaki kolor ma samochód), jednak może się zdarzyć, że w systemie wystąpią dwa różne obiekty o identycznym stanie. Wtedy jedyną możliwością rozróżnienia obiektów będzie ich tożsamość.

Obiekt • Zachowanie to zbiór usług, które obiekt potrafi wykonywać na rzecz innych obiektów. Zachowanie stanowi element dynamiki modelu (tzn. sposób działania systemu). W ramach tej dynamiki obiekty mogą prosić inne obiekty o wykonanie usług. Obiekt reaguje na taką prośbę, jeżeli usługa jest w zbiorze obsługiwanych przez niego usług. Prośby obiektów o wykonanie usług nazywane są komunikatami. W ramach wykonania usługi obiekt przeprowadza przetwarzanie danych, którego efektem może być zmiana stanu obiektu albo dostarczenie drugiemu obiektowi odpowiedniego rezultatu przetwarzania. Efekt wykonania usługi zależy od trzech rzeczy: stanu obiektu, parametrów komunikatu, stanu innych obiektów. Parametry to lista wartości obiektów, które pozwalają na sterowanie zachowaniem usługi. Usługa może się zatem zachowywać różnie w zależności od wartości parametrów. W trakcie wykonywania usługi obiekt może również poprosić inne obiekty o pomoc.

Klasa • Podstawową jednostką modelowania obiektowego nie jest obiekt, ale grupa obiektów. Staramy się zatem w jakiś sposób pogrupować (poklasyfikować) obiekty znajdujące się w modelowanej dziedzinie. Takie grupy podobnych do siebie w pewien sposób obiektów nazywamy klasami. SAMOCHÓD

Klasa • Klasa jest opisem grupy obiektów o jednakowym zestawie właściwości i sposobie zachowania. Opis klasy stanowi pewnego rodzaju wzornik dla tworzenia obiektów tej klasy (lub też dla sprawdzania, czy obiekt należy do klasy). Ten wzornik zawiera nazwę klasy, zestaw właściwości jednakowych dla wszystkich obiektów klasy oraz zestaw usług obsługiwanych przez wszystkie obiekty klasy. Każdy obiekt przynależny do danej klasy ma wszystkie właściwości umieszczone na liście właściwości tej klasy oraz dostarcza wszystkich usług dostarczanych przez klasę. Właściwości klasy nazywamy – atrybutami, a usługi operacjami (metodami).

Modelowanie struktury Każdy model powinien odwzorowywać strukturę modelowanego fragmentu rzeczywistości. Na etapie projektowania należy ustalić z jakich elementów składa się modelowany system lub modelowana dziedzina i w jaki sposób elementy te są ze sobą powiązane. Nie wystarczy znaleźć klas oraz określić ich atrybuty i operacje – należy również pokazać odpowiednią sieć zależności. Strukturę możemy prezentować na dwóch poziomach: na poziomie obiektów i na poziomie klas. Oznacza to, że na diagramach opisujących strukturę mogą się pojawić klasy, jak również obiekty. Należy je tak zdefiniować, by przy ich pomocy z wykorzystaniem związków przedstawić modelowaną dziedzinę problemową.

Modelowanie struktury Diagramy zawierające klasy umożliwiają pokazanie potencjalnych możliwości wchodzenia obiektów w interakcje ze sobą. Na diagramach tych można również pokazywać zwyczajne zależności między pojęciami w danej dziedzinie problemu. Przy takim podejściu diagramy te stanowią słownik dziedziny, w którym poszczególne klasy odpowiadają pojęciom słownikowym

Klasyfikacja diagramów opisu struktury dla języka UML Diagram opisu struktury Diagram składowych Diagram wdrożenia Diagram komponentów Diagram pakietów Diagram obiektów Diagram klas

Modelowanie dynamiki Drugim zasadniczym elementem modelowania jest ukazanie dynamiki modelowanego systemu. O ile w modelu struktury pokazujemy aspekty statyczne, to model dynamiki pokazuje system w działaniu. Model dynamiki jest o tyle istotny, że podczas konstrukcji oprogramowania staramy się zrealizować właśnie dynamiczną funkcjonalność systemu odpowiadającą wymaganiom zamawiających. Od dobrej specyfikacji, a potem realizacji dynamiki systemu zależy zatem jego jakość rozumiana jako spełnienie rzeczywistych potrzeb zamawiającego.

Modelowanie dynamiki Model dynamiki ukazuje system w działaniu zatem konieczne jest pokazanie następstwa czasu. Należy pokazać kolejności czynności wykonywanych przez system czy też kolejności interakcji w dialogu użytkownika z systemem. Ważne jest, aby model dynamiki miał ścisły związek z modelem struktury. Chodzi o to, żeby te dwa widoki na ten sam system były ze sobą zgodne. Oznacza to, że obiekty pojawiające się na diagramach opisujących dynamikę powinny mieć swoje odpowiedniki w obiektach lub klasach obrazowanych na diagramach opisu struktury.

Klasyfikacja diagramów opisu dynamiki dla języka UML Diagram opisu dynamiki Diagram interakcji Diagram maszyny stanów Diagram przypadków użycia Diagram czynności Diagram sekwencji Diagram następstwa Diagram komunikacji Diagram opisu interakcji

Definicja UML-a UML (ang. Unified Modeling Language – zunifikowany język modelowania) jest jednym z najbardziej rozpowszechnionych językiem specyfikacji do tworzenia obiektowo zorientowanych systemów. Jest to język modelowania wizualnego, pozwalający budowniczym systemów na tworzenie planów, na których ich wizje zostają uchwycone i wyrażone w standardowy, łatwy do zrozumienia sposób. Dostarcza też mechanizmów ułatwiających efektywną wymianę informacji.

Trochę historii Przed pojawieniem się UML-a rozwój systemów był zawsze mniej lub bardziej udaną próbą trafienia do celu. Analitycy systemowi starali się ocenić potrzeby klientów, następnie tworzyli analizę wymagań i warunków zapisaną w notacji jasnej dla nich, ale nie zawsze zrozumiałej dla klientów. Przekazywali tę analizę zespołowi programistów i mieli nadzieję, że produktem końcowym będzie system, którego klient oczekiwał.

Potrzeba matką wynalazków… UML został wymyślony przez Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona. Ci trzej – nazwani „Trzej Amigos"‘ – w latach osiemdziesiątych i dziewięćdziesiątych XX wieku pracowali w trzech różnych organizacjach, niezależnie rozwijając własne metodologie obiektowo zorientowanej analizy i projektowania. Ich osiągnięcia przewyższyły jakością dzieła innych analityków. W połowie lat 90 zaczęli od siebie nawzajem pożyczać pomysły, aż wreszcie zdecydowali się połączyć swoje wysiłki.

Potrzeba matką wynalazków… Połączyli oni swoje notacje, tworząc jedną metodę. Z poszczególnych notacji przejęto najlepsze rozwiązania. Booch metoda Boocha Rumbaugh OMT UML Jacobson przypadki użycia

Podstawowe elementy UML • Notacja – istotna przy szkicowaniu modeli: • o elementy graficzne, o składnia języka modelowania. • Należy pamiętać, że UML nie jest: o narzędziem - lecz specyfikacją dla narzędzi, o metodyką – nie określa metody projektowania, a zaleca jedynie stosowanie podejścia przyrostowego. Semantyka – tzw. metamodel – istotny przy programowaniu graficznym; zawiera: o definicje pojęć o powiązania między definicjami. • Należy pamiętać, że UML jest: o notacją graficzną – określa sposób zapisu modeli,

Diagramy – komponenty UML-a UML zawiera wiele elementów graficznych grupowanych w postaci diagramów. Ponieważ jest językiem, określa zasady łączenia tych elementów. Celem diagramów jest pokazanie wielu perspektyw systemu - ten zestaw perspektyw to model. Należy podkreślić, że model opisuje, co system ma robić, ale nie określa jak system ten ma zostać zaimplementowany. Model jest pojęciem przydatnym w nauce i inżynierii. W najogólniejszym sensie, tworząc model, używamy czegoś, co dobrze znamy, do zrozumiałego objaśnienia czegoś, o czym wiemy niewiele. Na kolejnych slajdach zostanie przedstawionych 8 wcześniej wspomnianych diagramów UML.

Diagram przypadków użycia Przypadek użycia jest bardzo przydatnym pojęciem, ponieważ pomaga analitykowi zrozumieć jak system powinien się zachowywać. Oprócz tego pozwala na zebranie wymagań stawianych systemowi przez użytkowników. Znaczenie przypadku użycia staje się jeszcze większe, kiedy zastosujemy jego wizualizację dostępną w UML. Sprawdzony jest fakt, że przyszli użytkownicy systemu wiedzą znacznie więcej, niż potrafią powiedzieć – pokazanie użytkownikowi diagramu przypadków użycia służy uzyskaniu dodatkowych informacji.

Diagram przypadków użycia Przypadek użycia jest inicjowany przez aktora, który: o wymaga dostępu do systemu, o reprezentuje punkt widzenia na system, o jest osobą fizyczną lub systemem zewnętrznym.

Diagram przypadków użycia Każdy przypadek użycia jest zbiorem scenariuszy, a każdy scenariusz – ciągiem kroków. Kroki te nie są pokazywane na diagramie przypadków użycia, nie ma ich także w notatkach – ich obecność pogorszyłaby klarowność diagramu, a właśnie ta cecha jest podstawową zaletą diagramów UML. Każdemu diagramowi w dokumentacji przeznaczana jest osobna strona. Podobnie jest ze scenariuszem – przeznacza się osobną stronę, na której znajdują się: o o o o aktor – który inicjuje przypadek użycia, warunki wstępne przypadku użycia, kroki scenariusza, warunki końcowe scenariusza, aktor – który czerpie korzyść z przypadku użycia, lista założeń (opcjonalnie) krótki opis

Związki między przypadkami użycia Zawieranie przypadków użycia oznaczamy linią przerywaną zakończoną strzałką wskazującą na niezależny przypadek użycia (czyli ten, od którego zależy inny przypadek). Nad linią związku zawierania umieszczamy w nawiasach francuskich <<include>>. Należy pamiętać, że zawierany przypadek użycia nigdy nie występuje samodzielnie, a jedynie wraz z przypadkiem użycia, który go zawiera.

Związki między przypadkami użycia Rozszerzenie Związek, który powoduje, że oryginalny ciąg zdarzeń zostaje uzupełniony o nowe kroki nazywamy rozszerzeniem. Rozszerzanie określa dodatkową funkcjonalność przypadku użycia. Rozszerzenie oznaczamy linią przerywaną zakończoną strzałką wskazującą na rozszerzany przypadek użycia Nad linią związku zawierania umieszczamy w nawiasach francuskich <<extend>>.

Związki między przypadkami użycia Uogólnienie Przypadki użycia mogą dziedziczyć po sobie zachowanie i wartości. Potomek, który dziedziczy po przodku, do otrzymanych cech przodka może dodać własne zachowanie. Związek uogólnienia może istnieć również między aktorami.

Przykład Zawieranie Rozszerzenie Uogólnienie

Diagram klas jest jednym z najczęściej stosowanych diagramów UML. Zazwyczaj zawiera największą ilość informacji i wykorzystuje największą liczbę symboli. Na diagramie prezentowane są klasy, atrybuty, operacje oraz powiązania między klasami. Budując diagram klas organizujemy podział odpowiedzialności pomiędzy klasy systemu i rodzaj wymienianych pomiędzy nimi komunikatów. Ilość danych zawarta na diagramie klas pozwala na bezpośrednie generowanie z niego gotowego kodu systemu.

Diagram klas nazwa atrybuty metody Klasa w UML przedstawiana jest jako prostokąt z wydzielonymi polami: nazwa, atrybuty i metody. Tradycyjnie nazwa klasy zaczyna się z dużej litery, jest pisana pogrubionym drukiem, a w przypadku klasy abstrakcyjnej – kursywą. Obiekt jest instancją klasy – nazwa obiektu jest umieszczana przed nazwą klasy i oddzielana od niej dwukropkiem.

Diagram klas – atrybuty klasy • Zazwyczaj atrybut klasy opisywany jest przez nazwę oraz typ. Jest to jednak definicja „okrojona”, ponieważ notacja UML obejmuje oprócz tych cech: widoczność (public– element jest widoczny z każdego miejsca w systemie, private – element jest widoczny we własnej klasie i jej podklasach, protected - element jest widoczny tylko we własnej klasie, package– element jest widoczny tylko wewnątrz własnego pakietu, krotność – określenie liczby obiektów mieszczących się w atrybucie, ograniczenia atrybutu oraz wartość domyślną. Jeżeli dla elementu podczas definicji nie podano wartości, to przypisywane są one w sposób domyślny – widoczność: prywatna, krotność: 1. widoczność nazwa : typ[krotność] {ograniczenia} = wartość_dom

Diagram klas Często zdarza się, że system wykorzystuje atrybut wyliczany na podstawie innych atrybutów. Takiego atrybutu nie ma potrzeby definiować w klasie – ponieważ jego wartość obliczana jest w czasie rzeczywistym. Atrybuty takie oznaczone są znakiem / umieszczonym przed nazwą.

Diagram klas Metoda (zwana również operacją) jest procesem, który klasa może wykonać: widoczność nazwa (parametr 1, parametr 2, . . . ) : typ {ograniczenia}. Parametr dla metody zadawany jest w formie: kierunek nazwa typ[krotność] = wartość dom. Możliwe kierunki parametrów: o o in: wejściowy (domyślny) out: wyjściowy inout: wejściowo-wyjściowy return: zwracany z metody

Diagram klas – związki między klasami Zależność to najsłabszy i jednocześnie najprostszy typ relacji między klasami. Przez zależność rozumie się, że zmiana jednej klasy wpływa na drugą: o o «call» - operacje w klasie A wywołują operacje w klasie B «create» - klasa A tworzy instancję klasy B «instantiate» - obiekt A jest instancją klasy B «use» - do zaimplementowania klasy A wymagana jest klasa B

Diagram klas – związki między klasami Asocjacja obrazuje czasowe powiązanie pomiędzy obiektami dwóch klas i jest często jest wykorzystywana jako alternatywny i równorzędny sposób zapisu cech klasy. Asocjacje są mocniejszymi związkami od zależności. Wskazują, że jeden obiekt jest związany z innym przez pewien okres czasu. Należy pamiętać, że czas życia obu obiektów nie jest od siebie zależny – usunięcie jednego nie powoduje usunięcia drugiego. W przypadku asocjacji obiekt nie jest właścicielem drugiego: nie tworzy go, nie zarządza nim, a moment usunięcia drugiego obiektu nie jest z nim związany.

Diagram klas – związki między klasami Agregacja to silniej wiążąca formą asocjacji. W tym przypadku równowaga między klasami jest zaburzona: określony jest właściciel oraz obiekt podrzędny, które wiąże czas życia. Właściciel nie jest wyłącznym właścicielem obiektu podrzędnego, nie tworzy i nie niszczy go. Relację agregacji zaznacza się ciągłą linią łączącą klasy/obiekty, zakończoną białym rombem po stronie właściciela Uogólnienie to związek między elementem ogólnym a elementem szczególnym. Związek ten określa hierarchię klas oraz pozwala ustalić części wspólne grupy klas. Potomek dziedziczy wszystkie właściwości przodka (atrybuty i operacje).

Klasy abstrakcyjne i elementy statyczne Dodatkowe właściwości klasy: o abstrakcyjna klasa (abstract class) (nazwa klasy napisana kursywą) – klasa nie może mieć bezpośredniego egzemplarza, o elementy statyczne (static elements) – atrybuty lub operacje mogą być statyczne (nazwa podkreślona) – dostępne są również bez konkretnego egzemplarza klasy.

Diagram obiektów zawiera obiekty oraz zachodzące miedzy nimi związki. Przedstawia statyczny egzemplarzy elementów występujących na diagramie klas. Można powiedzieć, że jest to rodzaj instancji diagramu klas – co widać po użytych symbolach. Różnica jest taka, że nazwy egzemplarzy są podkreślone, a nazwa klasy poprzedzona jest dwukropkiem. Diagramy obiektów są rzadziej stosowane. Projektanci sięgają po nie dopiero, gdy diagram klas nie pozwala na wymodelowanie zawiłych aspektów systemu.

Diagram komponentów Komponenty są fizycznymi częściami systemu i istnieją w rzeczywistości, a nie jedynie w umysłach analityków. Komponentem może być: baza danych, tabela, plik wykonywalny itp. Należy pamiętać, że jeden komponent może być implementacją wielu klas. Diagramy komponentów tworzy się aby: o ukazać pełną strukturę systemu, o twórcy oprogramowania poznali strukturę, do której mają dążyć, o twórcy dokumentacji rozumieli o czym piszą, o możliwe było wielokrotne stosowanie komponentów.

Diagram komponentów zawiera komponenty, interfejsy (czyli zestaw operacji dotyczących określonych zachowań komponentu, ale także klasy) oraz związki między nimi. Ponieważ komponent może być instancją klasy – diagram ten służy także jako reprezentacja zależności między klasą a komponentem.

Diagram komponentów Kiedy komponenty są powiązane relacją zależności, oznacza to, że wymagają siebie do realizacji ich własnej funkcjonalności. Ponadto kiedy komponent A korzysta z komponentu B to zmiana w komponencie B może spowodować konieczność zmiany w A. Ilość i zależności ma duże znaczenie dla oceny jakości modelu i projektu: wiele powiązań pomiędzy komponentami utrudniają wyznaczanie obszarów zmienności oraz hermetyzację, jednak system o dobrze zdefiniowanych interfejsach komponentów pozwala na ich wymianę bez potrzeby modyfikacji pozostałej części systemu.

Diagram przebiegu (sekwencji) Diagramy sekwencji intuicyjnie prezentują kolejność wywołań operacji, przepływ sterowania pomiędzy obiektami oraz szablon realizowanego algorytmu. Pomijają natomiast całkowicie aspekt dostępu i operacji na danych, związany z komunikacją. Uczestnikami diagramów sekwencji są obiekty, opisane nazwą obiektu i jego klasą, które wymieniają między sobą komunikaty.

Diagram przebiegu (sekwencji) Diagram przebiegu składa się z obiektów (prostokąty z nazwami), komunikatów (strzałki) i czasu (rozumianego jako przesunięcie wzdłuż pionowej osi). Od każdego obiektu biegnie linia przerywana nazywana linią życia obiektu. Prostokąt umieszczony na przerywanej linii jest aktywacją – czyli wykonaniem operacji przez obiekt (im dłuższy prostokąt, tym dłuższy czas trwania operacji)

Diagram przebiegu Komunikaty biegną między liniami życia od obiektu wysyłającego do obiektu docelowego. Rodzaje komunikatów: o Prosty – przekazuje sterowanie od obiektu do obiektu, o Synchroniczny – po jego wysłaniu obiekt oczekuje odpowiedzi, a dopiero po jej uzyskaniu przechodzi do dalszych działań, o Asynchroniczny – obiekt kontynuuje działania bez oczekiwania na odpowiedź.

Diagram przebiegu Czas w diagramie sekwencji przedstawiany jest jako przesunięcie względem pionowej osi. Odliczanie zaczyna się od góry diagramu, a upływowi czasu odpowiada przesunięcie w dół. Komunikaty znajdujące się wyżej są wcześniejsze od tych, które są umieszczone niżej.

Diagram kooperacji Jest rozszerzeniem diagramu obiektów – oprócz powiązań między obiektami pokazuje przesyłane między nimi komunikaty. Komunikaty to strzałki umieszczone wzdłuż linii powiązań istniejących między obiektami (zawsze wskazują adresata komunikatu). Komunikat zwykle nakazuje obiektowi, który go otrzymał wykonanie pewnej operacji. Dodatkowo może on zawierać atrybuty, będące parametrami niezbędnymi do przeprowadzenia operacji. wrzuć (wpłata, wybór) r) bó y w z( rc 3: ta os d 2 : dostarcz (wybór) 1 : wyślij (wpłata, wybór)

Diagram stanów Charakteryzując system można stwierdzić, że jego obiekty zmieniają stan w odpowiedzi na zdarzenia i interakcje. Tego rodzaju zmiany przedstawiane są na diagramie stanów – prezentuje on stany obiektów i przejścia między nimi od rozpoczynającego ciąg stanu początkowego po ostatni w kolejności stan końcowy. Diagram stanów bywa nazywany maszyną stanów lub maszyną stanową.

Diagram stanów Podstawowe elementy diagramu to stany obiektu połączone strzałkami przejść. Obiekt, reaguje na nadchodzące zdarzenia, jeżeli spełnione są określone warunki, zmienia stan oraz położenie na diagramie stanu. Diagram stanów interfejsu graficznego ze stanem oszczędzania monitora i warunkiem dozoru

Diagram czynności [rozładowana] [pełna] Diagram czynności jest rozszerzeniem diagramu stanów – obrazuje wszystko to, co się dziej podczas wykonywania operacji i w trakcie danego procesu. Diagram stanów ukazywał oprócz stanów także czynności (w postaci strzałek), które to są najbardziej eksponowane na diagramie czynności. Czynności reprezentowane są przez zaokrąglone prostokąty (bardziej owalne od ikon stanów). Po zakończeniu procesów składających się na daną czynność następuje automatyczne przejście do następnej czynności reprezentowane przez strzałkę z odpowiednim zwrotem.

Diagram czynności Ciąg czynności prawie zawsze prowadzi do punktu, w którym musi zostać podjęta decyzja – stąd na poprzednim slajdzie w diagramie czynności pojawiła się decyzja (romb z rozgałęzieniem). Zawsze obok strzałek wychodzących z decyzji muszą być zamieszczone warunki dozoru na podstawie których zostało podjęte odpowiednie działanie. Podczas modelowania czynności zdarzają się sytuacje, w których należy rozdzielić przejście na dwie współbieżne ścieżki. Przepływ sterowania następuje w takim przypadku w tym samym czasie, by na końcu połączyć się ponownie.

Diagram czynności W ciągu czynności może się zdarzyć wysłanie sygnału. Przejście sygnału powoduje wykonanie czynności. Tory – równoległe segmenty pokazujące podział obowiązków; każdy tor jest przypisany do innej osoby (działu, firmy, urządzenia), odpowiedzialnej za wykonanie danej czynności

Diagram czynności – podział na tory TORY

RUP - Rational Unified Process RUP jest to szablon iteracyjnego wytwarzania oprogramowania. Dokonując przystosowania z szablonu RUP należy wybrać elementy w zależności od konkretnych potrzeb. Twórcy procesu skupili się na projektach zakończonych niepowodzeniem (próbowali poznać ich przyczyny) - studiowali inżynierię oprogramowania oraz jej sposoby rozwiązywania problemów zaistniałych w projektach. Wyodrębniono najczęstsze błędy zespołów projektowych: – – – – Brak zarządzania wymaganiami Niejednoznaczna, nieprecyzyjna komunikacja Niska skalowalność i rozszerzalność systemów, Wysoka złożoność oprogramowania Nieporozumienia w specyfikacji i projekcie Zlekceważenie etapu testowania Subiektywna ocena projektu przez kierownika Lekceważenie ryzyka Niepowodzenie projektu było spowodowane kombinacją wielu czynników (w każdym projekcie w specyficzny sposób). Rezultatem badań firmy Rational było opracowanie zbioru dobrych praktyk, które nazwane zostały Rational Unified Process.

RUP - Rational Unified Process Proces RUP nawiązuje w budowie do procesu spiralnego znanego z inżynierii oprogramowania – wynika stąd, że jest to proces iteracyjnego wytwarzania oprogramowania. Dzięki zastosowaniu podejścia przyrostowego osiągnięto: o integrację oprogramowania - ograniczenie do mniejszej liczby elementów (zyskanie prostoty i redukcji kosztów), o poszczególne składowe oprogramowania są projektowane osobno, nastąpił wzrost ponownego użycia modułów, o efektywny sposób zarządzania wymaganiami i zmianami, o każda iteracja pozwala wykryć pojawiające się w czasie trwania projektu czynniki ryzyka.

Związek między czynnościami, etapami i iteracjami

Wnioski • Jest to notacja graficzna – ludzki mózg doskonale radzi sobie z rozpoznawaniem graficznych symboli, dlatego z reguły możemy patrząc na diagramy łatwo zrozumieć cel i przekaz ich projektanta, • UML pozwala skupić uwagę na najważniejszych koncepcjach lub pomysłach i pominąć bądź ukryć nieistotne szczegóły, • Dzięki programom wspomagającym tworzenie diagramów UML możliwe jest wygenerowanie nawet do 60% kodu (przy prawidłowo wykonanych schematach UML).

Wnioski • Diagramy powstałe w UML mogą być różnie interpretowane – każdy diagram ma zazwyczaj liczbę interpretacji równą liczbie osób, które go oglądały, • UML to tylko rysunki – nie są w stanie zastąpić szczegółowego opisu oraz bezpośrednich konsultacji – nie należy na nich za bardzo polegać, • Budując diagramy należy cały czas pamiętać o istocie projektu – diagramów jest dużo i chce się je wszystkie wykorzystać – jednak z reguły nie ma takiej potrzeby!

Bibliografia • M. Śmiałek – Zrozumieć UML 2. 0 • J. Schmuller – UML dla każdego • S. Si Alhir – UML wprowadzenie