Język UML w projektowaniu oprogramowania

Transkrypt

1 Język UML w projektowaniu oprogramowania Autor: Jawor & others źródła: - czyjś pdf z paczki Mojziaka - prezentacja K. Materla, P. Stasiak - Martin Fowler: UML w Kropelce - Russ Milles, Kim Hamilton: Learning UML Co to jest UML? UML (ang. Unified Modeling Language, czyli Zunifikowany Język Modelowania) jest to język formalny wykorzystywany do modelowania różnego rodzaju systemów. Język modelowania może występowad w formie kodu, pseudokodu, obrazów, diagramów lub nawet fragmentów tekstowych. Elementami tworzącymi język modelowania jest notacja (czyli elementy wyrażające model). Sam język UML nie określa metody modelowania, a jedynie zaleca podejście przyrostowe i jest specyfikacją dla narzędzi. UML ma 6 następujących zalet: - Jest językiem formalnym Każdy z elementów języka ma swoją określoną definicję więc nie ma niebezpieczeostwa złego zrozumienia danego elementu systemu - jest zwięzły cały język składa się z prostych i zwięzłych notacji - jest wyczerpujący opisuje wszystkie możliwe aspekty systemu - jest skalowalny w razie potrzeby język potrafi opisywad potężne projekty systemów, z drugiej strony da się je uprościd do mniejszych i bardziej ogólnych sytuacji - zbudowany na wieloletnim doświadczeniu, bazujący na najlepszych praktykach społeczności projektującej obiektowo - jest standardem UML złożony jest z dwóch podstawowych elementów: notacji(reprezentacja graficzna, elementy graficzne, które widad w modelach składnia języka modelowania) oraz metamodelu (definicje pojęd i powiązania, jest to nadanie modelom większej ścisłości bez poświęcania ich przydatności). W modelowaniu ważniejsza jest notacja, natomiast podczas generowania kodu ważniejszy jest metamodel. Języka UML można używad podczas tworzenia wyprzedzającego jak i odtwarzania wstecznego. Oznacza to, że diagram UML można stworzyd przed napisaniem kodu programu jak również można go skonstruowad dla istniejącego kodu w celu lepszego zrozumienia go. Język został stworzony z myślą o prezentowaniu szkiców, które mogą zostad narysowane na kartce papieru. Mają charakter nieformalny i dynamiczny. Najczęściej rozpatrywane są one szybko i w grupie. Rzadko kto wówczas trzyma się wszystkich zasad języka UML. Projektowanie oprogramowania jest zadaniem trudnym i złożonym, najczęściej angażującym wiele osób o różnych sposobach postrzegania projektowanego systemu. Aby to uwzględnid często stosuje się podejście z 4+1 perspektywą. Cztery pierwsze opisują wewnętrzną strukturę systemu na różnych poziomach abstrakcji i szczegółowości. Ostatnia perspektywa opisuje funkcjonalnośd systemu widzianą przez jego użytkowników. Każda perspektywa korzysta z własnego zestawu diagramów. Perspektywa przypadków użycia opisuje funkcjonalnośd, jaką powinien dostarczad system, widzianą przez jego użytkowników Perspektywa logiczna zawiera sposób realizacji funkcjonalności, strukturę systemu widzianą przez projektanta Perspektywa implementacyjna opisuje poszczególne moduły i ich interfejsy wraz z

2 zależnościami (dla programisty) Perspektywa procesowa zawiera podział systemu na procesy (czynności) i procesory (jednostki wykonawcze); opisuje właściwości pozafunkcjonalne systemu (dla programistów i integratorów) Perspektywa wdrożenia definiuje fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze (dla integratorów i instalatorów) Diagram przypadków użycia Przypadki użycia systemu to technika wyznaczania funkcjonalnych wymagao systemu. Ich działanie polega na opisywaniu typowych interakcji między użytkownikami systemu a samym systemem, czyli opowiadaniu, w jaki sposób system jest używany. Często przed stworzeniem diagramu przypadków użycia definiuje się scenariusze. Scenariusz jest to ciąg kroków opisujących interakcję między użytkownikiem a systemem. Przedstawia on zazwyczaj sytuacje, które mogą się wydarzyd. W terminologii przypadków użycia systemu użytkowników nazywa się aktorami. Aktor jest to funkcja, którą użytkownik pełni w stosunku do systemu. Jeden aktor może występowad w wielu przypadkach użycia i na odwrót - przypadek użycia może byd wykonywany przez wielu aktorów. Wyróżniamy aktorów osobowych i nieosobowych. Aktorem osobowym może byd osoba, zespół, dział, instytucja, organizacja, zrzeszenie organizacji lub organizacja wirtualna. Nazwy aktorów osobowych często pokryte są z nazwami funkcji jakie pełnią w organizacji, projekcie lub przedsięwzięciu bądź nazwą stanowiska jakie piastują. Natomiast aktorem bezosobowym może byd system zewnętrzny (podsystemy, bazy danych), urządzenie lub czas. Przypadek użycia reprezentuje konkretną funkcjonalnośd ale bez prezentowania jej szczegółów. Przypadki mogą byd powiązane ze sobą relacjami uogólnienia, rozszerzania i zawierania. Diagramy Klas Klasy opisują różne typu obiektów, które są potrzebne do odwzorowania założeo systemu. Diagramy klas są częścią perspektywy logicznej. Diagramy klas opisują typy obiektów w systemie oraz różne rodzaje statycznych relacji między nimi. Diagram taki pokazuje również atrybuty oraz operacje klas oraz ograniczenia tego w jaki sposób obiekty mogą byd powiązane. W ogólności atrybuty i operacje nazywa się cechami. Cechy reprezentują strukturalne właściwości klasy. Atrybuty zapisywane są jako wiersz tekstu umieszczony w ramce klasy: specyfikator-dostępu nazwa : typ krotność = wartość domyślna {opis-cechy} np. public nazwa : String [1] = Bez Nazwy {read-only} Wymagana jest tylko nazwa. Inne atrybuty są opcjonalne. - Specyfikacja: zasięg, np. prywatny, publiczny - nazwa: w jaki sposób system ma identyfikowad atrybut - typ: określa rodzaj obiektu - krotnośd: wskazuje ile obiektów może zawierad dana cecha - wartośd domyślna - opis cechy: wskazuje dodatkowe atrybuty, właściwości.

3 Podobnie wygląda zapis operacji: specyfikator-dostępu nazwa (lista-parametrów): typ-wyniku {opis-cechy} Przykład wyglądu klasy w diagramie poniżej: Asocjacje są innym sposobem prezentacji cech obiektu. Większośd z cech, które zostały wyszczególnione powyżej można zapisad w formie asocjacji. Przykładowo: Asocjacja występuje pod postacią strzałki. Jej początek określa źródło, zaś grot wskazuje cel. Przy strzałkach przedstawione są dodatkowo inne cechy. Klasy mogą byd powiązane ze sobą na kilka możliwości: zależnośd - najsłabszy rodzaj relacji. Występuje gdy zmiana definicji jednej klasy może spowodowad zmianę drugiej - np. operacja w klasie A wywołuje operacje w klasie B. Asocjacja - obiekt powiązany asocjacją z drugim posiada referencję do niego, ale nie jest jego właścicielem. Asocjacja jest równoważna z atrybutami. Agregacja - silniejsza forma asocjacji. Istnieje właściciel i obiekt podrzędny. Kompozycja - najsilniejsza relacja łącząca kasy. Podobnie jak w Agregacji istnieje właściciel i obiekt podrzędny, ale właściciel i obiekt nie mogą istnied bez siebie.

4 Powyżej zaprezentowane zostały asocjacje jednokierunkowe. Możliwe są jeszcze asocjacje dwukierunkowe, w której przechodząc z jednej cechy do drugiej mamy możliwośd powrócid do cechy wcześniejszej. Diagramy Obiektów Diagramy obiektów obrazują obiekty występujące w systemie i ich związki. Są one zazwyczaj wykorzystywane do wyjaśnienia znaczenia diagramów klas.diagram ten posługuje się identycznymi symbolami co diagram klas, jednak, dla odróżnienia obiektów od klas, nazwa składa się z nazwy obiektu i nazwy klasy, oddzielonych dwukropkiem. Diagramy obiektów przydają się w przypadku szczególnie skomplikowanych zależności, których nie można przedstawid na diagramie klas. Wówczas przykładowe konfiguracje obiektów pomagają w zrozumieniu modelu. Diagram sekwencji Diagram sekwencji (z grupy diagramów interakcji) prezentuje jak współpracują ze sobą grupy obiektów. Zwykle diagram sekwencji tyczy się jednego przypadku użycia. Pokazuje kilka przykładowych obiektów i komunikaty między nimi wymieniane z zachowaniem ich kolejności. Rodzaje komunikatów:

5 Każdy z obiektów przedstawiany jest za pomocą linii czasu. Na każdej linii czasu umieszczane są słupki aktywności reprezentujące chwile, w których użytkownik bierze udział w interakcji. Oznaczają one obecnośd jednej z metod uczestnika na stosie wywołao. Przykładowy diagram: Możliwe jest również prezentowanie pewnych bloków zdarzeo o specjalnej własności, np. sekcja krytyczna, pętla, instrukcja warunkowa Wówczas używa się bloków. Na diagramach sekwencji taką grupę operacji obejmuje się prostokątem, w którego lewym górnym narożniku, w pięciokącie umieszcza się słowo kluczowe lub opis określający znaczenie danego bloku (tzw. operator interakcji) OPERATORY INTERAKCJI - alt (od alternative ) - określający warunek wykonania bloku operacji, odpowiadający instrukcji if-else - opt (od optional ) - reprezentujący instrukcję if (bez else ) - par (od parallel ) - nakazujący wykonad operacje równolegle - critical - blok atomowy, oznaczający obszar krytyczny - loop - definiujący pętlę typu for lub while - break - wykonanie fragmentu i zakooczenie interakcji - seq - słaba sekwencja (podobnie do współbieżności) dotyczy zdarzeo z kilku linii - ignore/consider - ignore(komunikat1, komunikat2,...) oznacza, że na diagramie nie pokazano wymienionych komunikatów, chod mogą wystąpid. Consider = odwrotnie Diagram aktywności (czynności) Diagramy czynności to technika opisywania logiki działania systemu, procesów biznesowych i przepływów pracy. Odgrywają rolę podobną do schematów przepływu danych, ale różnią się tym, że potrafią pokazad działania równoległe. Diagram określa wówczas najważniejsze zasady dotyczące kolejności wykonywania czynności, których należy się trzymad. Samo zaś wykonanie poszczególnych zadao w procesach równoległych jest dowolne. Mówi w jaki sposób osiągnąd zamierzony cel. Jest przydatny przy modelowaniu sytuacji decyzyjnych, operacji, algorytmów, procesów systemowych. Naturalnie w przypadku działao równoległych pojawia się zagadnienie synchronizacji, które należy rozwiązad.

6 Przykład diagramu podczas sytuacji decyzyjnej: Przykład diagramu podczas wykonywania procesów równoległych: Diagramy maszyny stanów Używany przy analizie i projektowaniu oprogramowania. Pokazuje przede wszystkim możliwe stany obiektu oraz przejścia, które powodują zmianę tego stanu. Można też z niego odczytad, jakie sekwencje sygnałów (danych) wejściowych powodują przejście systemu w dany stan, a także jakie akcje są podejmowane w odpowiedzi na pojawienie się określonych stanów wejściowych. Tym samym tworzony jest cykl życia obiektu, który może byd tym istotniejszy w procesie wytwarzania oprogramowania, im więcej jest możliwych stanów obiektu. Diagram składa się z określonych stanów. Zawiera również reguły, na podstawie których kontroler zmienia swój stan z jednego na drugi. Reguły pokazane są za pomocą przejśd linii łączących stany. Każde przejście ma etykietę złożoną z dwóch części: wyzwalacz [dozór] / czynność Wyzwalacz pojedyncze zdarzenie uruchamiające zmianę stanu Dozór wyrażenie logiczne, które musi byd prawdziwe, aby przejście mogło zostad zrealizowane Czynnośd zachowanie wykonywane podczas przejścia z jednego stanu w drugi Przykład: