Modelowanie z wykorzystaniem UML Bartosz Walter Bartosz Waltercs

Plan dnia A 1. Wprowadzenie do UML A 2. Modelowanie struktury statycznej A 3. Implementacja w Rational Rose B 1. Modelowanie zachowań i podziału B 2. Zaawansowane elementy UML B 3. Implementacja w Rational Rose 2 © 2001 -2005 Bartosz Walter

Wprowadzenie do UML Obiektowe spojrzenie na świat czyli o modelowaniu, obiektach i języku 3

Czym jest model? Świat rzeczywisty Model System komputerowy Model to „układ (. . . ) możliwie mało skomplikowany, działający analogicznie do oryginału” - Słownik Języka Polskiego, PWN 1998 4 © 2001 -2005 Bartosz Walter

Analiza i modelowanie systemów Elementy świata i modelu – użytkownicy, systemy zewnętrzne; – dane, ich struktura, sposób przetwarzania, zależności statyczne i dynamiczne; – procesy, ich struktura i rozmieszczenie; –. . Metodyka modelowania jest opisem czynności, sposobu i kolejności ich realizacji; czynności te mają prowadzić ku MODELOWI, zapewniając jednocześnie metody utrzymania wysokiej jakości (spełnienia wymagań użytkownika) 5 © 2001 -2005 Bartosz Walter

Istota modelowania Czym jest analiza? „analiza to studium problemu przed podjęciem działania” Tom De. Marco, 1978 Sposoby zarządzania złożonością: – – – – abstrakcja: omijanie rzeczy nieistotnych hermetyzacja: ukrywanie rzeczy złożonych dziedziczenie: uogólnianie wspólnych cech kojarzenie: porównywanie analogii komunikacja: jak porozumiewają się elementy modelu skalowanie: dopasowanie optyki do rozmiaru problemu klasyfikacja: grupowanie zachowań elementów modelu. 6 © 2001 -2005 Bartosz Walter

Cele modelowania 1. divide et impera, czyli dekompozycja 2. łatwiejsze wyobrażenie systemu 3. specyfikacja struktury i zachowania 4. dokumentacja decyzji podjętych w trakcie realizacji 7 © 2001 -2005 Bartosz Walter

Cztery zasady modelowania 1. wybrany model determinuje rozwiązanie 2. modelować można na różnych poziomach szczegółowości 3. najlepsze modele odpowiadają rzeczywistości 4. żaden model nie jest wystarczający 8 © 2001 -2005 Bartosz Walter

W świecie obiektowym Elementy świata – świat składa się z obiektów – procesy i dane są zintegrowane Komunikacja między nimi – obiekty komunikują się za pomocą przekazywania zdarzeń Ten model jest łatwy do zrozumienia! 9 © 2001 -2005 Bartosz Walter

Klasy i obiekty Cel: reprezentacja za pomocą pewnego elementu świata zmiana cyklu rozwoju na bardziej elastyczny dostosowanie metod analizy do języków OOP Obiekt: reprezentacja konkretnego elementu świata, posiadająca pewne cechy i oferująca pewne usługi Klasa: zbiór obiektów podobnych lub o wspólnych cechach 10 © 2001 -2005 Bartosz Walter

Czym jest UML? UML oznacza Zunifikowany Język Modelowania (Unified Modelling Language) UML jest językiem wizualizacji, specyfikacji, konstrukcji i dokumentacji artefaktów związanych z tworzeniem oprogramowania Model UML jest wypadkową wielu widoków różnych aspektów systemu. UML abstrahuje od obiektu modelowania i metodologii modelowania 11 © 2001 -2005 Bartosz Walter

Unifikować, czyli łączyć UML łączy najlepsze cechy: – modelowania danych (EER) czyli - jak przedstawić informację? – modelowania czynności (DFD) czyli - co się dzieje w systemie? – modelowania obiektowego (OOA) czyli - jak zrozumiale przedstawiać świat? – zarządzania złożonością (komponenty) czyli - divide et impera! 12 © 2001 -2005 Bartosz Walter

UML w skrócie • 9 typów diagramów - perspektyw – modelowanie wymagań – modelowanie struktury statycznej koncepcji – modelowanie zależności dynamicznych i zachowań – modelowanie struktury fizycznej • mechanizm rozszerzeń – stereotypy (ang. stereotypes) – metki (ang. tags) – ograniczenia (ang. constraints) 13 © 2001 -2005 Bartosz Walter

UML: typy diagramów – – – – przypadków użycia (use-case diagram) klas i obiektów (class diagram) stanu obiektów (statechart diagram) współpracy (collaboration diagram) sekwencji (sequence diagram) czynności (activity diagram) komponentów (component diagram) rozmieszczenia (deployment diagram) 14 © 2001 -2005 Bartosz Walter

Historia UML Dawno temu. . . – różnorodne, niespójne metodyki obiektowe (OMT, OOSE, Fusion, OOA/OOD) Początki UML i Trzej Amigos – 1994 - prace nad Metodą Zunifikowaną – 1995 - wersja 0. 9 UML J. Rumbaugh G. Booch I. Jacobson © 2001 -2005 Bartosz Walter 15

Historia UML (cd. ) Rozwój UML – I. 1997 - wersja 1. 0 UML – XI. 1997 - standaryzacja przez OMG Obecnie – wersja 1. 4 UML – prace nad 2. 0 UML http: //www. omg. org/uml/ http: //www. rational. com/uml/ 16 © 2001 -2005 Bartosz Walter

Wsparcie ze strony przemysłu SW UML Partners Consortium udział największych firm produkujących oprogramowanie: – DEC, HP, Microsoft, IBM, Oracle, Texas Instruments oraz producenci CASE – Rational Software 17 © 2001 -2005 Bartosz Walter

Cykl tworzenia oprogramowania UML jest niezależny od procesu ale twórcy sugerują proces; – ukierunkowany na przypadki użycia zorientowany na architekturę – iteracyjny i przyrostowy 18 © 2001 -2005 Bartosz Walter

Przykład 1. Biblioteka prowadzi wypożyczalnię wydawnictw: książek i czasopism. Korzystają z niej czytelnicy. 2. Wszystkie wydawnictwa mogą występować w wielu egzemplarzach. 3. Czytelnicy mogą rezerwować i odwoływać rezerwacje na wydawnictwa. 4. Książka może być dostępna, wypożyczona, zaginiona, lub zniszczona. 19 © 2001 -2005 Bartosz Walter

Statyczne zachowanie systemu Jak modelować funkcjonalność czyli o przypadkach użycia 20 © 2001 -2005

Aktor, czyli działacz Aktor to ktoś (coś), kto (co) musi współdziałać z modelowanym systemem.

Aktor w UMLu jest klasą (nie obiektem!) o nadanym stereotypie Actor. Można go oznaczać

Przypadek użycia (use-case) – jest sposobem, w jaki aktorzy używają (chcą używać) systemu – jest podstawową jednostką funkcjonalności. – definiuje wymagania Czego potrzebują użytkownicy? – Bibliotekarz. . . – Czytelnik. . . 23 © 2001 -2005 Bartosz Walter

Diagram use-case Definiuje – granice systemu, czyli jak daleko sięga model – jego kontekst, czyli co pozostaje na zewnątrz – użytkowników systemu, czyli aktorów – funkcje systemu, – zależności między użytkownikami i funkcjami . . . i jest czytelny dla odbiorcy! 24 © 2001 -2005 Bartosz Walter

Przykład diagramu use-case 25 © 2001 -2005 Bartosz Walter

Użycie funkcji Aktor używa funkcji (wykonuje funkcję) – domyślny stereotyp <<communicates>> – od użytkownika

Zależności między funkcjami (cd. ) Funkcja uszczegóławia funkcję – relacja dziedziczenia – stereotyp <<extends>> – funkcje abstrakcyjna – od funkcji szczegółowej do funkcji ogólnej 27 © 2001 -2005 Bartosz Walter

Zależności między funkcjami (cd. ) Funkcja wywołuje inną funkcję – relacja zależności funkcji – ponowne użycie funkcji/komponentu – stereotyp <<uses>> – od funkcji wołającej do funkcji wołanej 28 © 2001 -2005 Bartosz Walter

Statyczne zachowanie systemu Modelowanie struktury danych czyli o diagramach klas i obiektów 29 ©

Klasa w UML Klasa przedstawia elementy świata o podobnej semantyce i podobnym zachowaniu. Posiada nazwę, operacje i atrybuty. – nazwa pochodzi z dziedziny zastosowania – standard nazywania klas Jak wyodrębnić klasy? 30 © 2001 -2005 Bartosz Walter

Zakres widoczności operacji i atrybutów + publiczne (public) – widoczne dla wszystkich # chronione (protected) – widoczne dla potomków – prywatne (private) – widoczne wewnątrz klasy (kontenera) – implementacyjne (implementation) – widoczne wewnątrz pakietu (nadkontenera) 31 © 2001 -2005 Bartosz Walter

Operacje to usługi oferowane przez klasę – argumenty i typ wartości – interfejs i deklaracja a definicja – operacje statyczne ich zakres obejmuje klasę a nie obiekt – operacje abstrakcyjne posiadają tylko deklarację operacji, definicje są w klasach potomnych 32 © 2001 -2005 Bartosz Walter

Atrybuty to informacje zawarte w klasie/obiekcie – cechy klasy/obiektu – relacje z innymi klasami/obiektami – atrybuty statyczne – atrybuty wywiedzione (derived) ‘/’ – typy atrybutów Jak odróżnić klasę od atrybutu? 33 © 2001 -2005 Bartosz Walter

Asocjacje Reprezentują relacje, w jakich znajdują się klasy/obiekty – posiadają liczność (krotność) – wiążą 1 lub więcej klas – mogą być nazwane i posiadać role – mogą mieć własności i ograniczenia 34 © 2001 -2005 Bartosz Walter

Krotność asocjacji Oznacza liczbę obiektów (nie klas!), które są ze sobą skojarzone – określone przez dolny i górny zakres – określane liczbą naturalną (0, 1, 2, . . . ) lub gwiazdką (* - dowolna liczba) – mają duże znaczenie na etapie projektu Jaka jest różnica między oznaczeniami: * i 1. . * ? 35 © 2001 -2005 Bartosz Walter

Agregacje Modelują relację część-całość – agregacja współdzielona (shared) - część może należeć do wielu całości – agregacja składowa (composition) - część jest ściśle uzależniona od całości 36 © 2001 -2005 Bartosz Walter

Zależność Jest ogólnym określeniem zależności (dependency) dwóch klas/obiektów – od klasy zależnej do nadrzędnej – często używane ze stereotypem – powiązanie elementów na różnych poziomach abstrakcji 37 © 2001 -2005 Bartosz Walter

Dziedziczenie Potomek dziedziczy cechy przodka – ułatwia zarządzanie złożonością – zakres widoczności w dziedziczeniu – klasa abstrakcyjna jako przodek dostarcza tylko definicji operacji – polimorfizm operacji – tryby dziedziczenia: overlapping, disjoint, complete, incomplete 38 © 2001 -2005 Bartosz Walter

Dziedziczenie (cd. ) przykładowy diagram dziedziczenia 39 © 2001 -2005 Bartosz Walter

Przykład diagramu klas 40 © 2001 -2005 Bartosz Walter

Diagram klas (cd. ) – Tytuł jest klasą abstrakcyjną – Książka i Czasopismo są specjalizacjami Tytułu – Czytelnik może mieć wiele Wypożyczeń – Wypożyczenie dotyczy jednego Czytelnika 41 © 2001 -2005 Bartosz Walter

Case Study Biblioteka: opis na załączonych kartkach 42 © 2001 -2005 Bartosz Walter

Case Study 43 © 2001 -2005 Bartosz Walter

Case Study 44 © 2001 -2005 Bartosz Walter

Case Study 45 © 2001 -2005 Bartosz Walter

Case Study 46 © 2001 -2005 Bartosz Walter

Literatura • G. Booch i in. "UML – przewodnik użytkownika", WNT 2001 • M. Fowler „UML w kropelce”, LT&P 2002 • S. S. Alhir “UML in a nutshell”, O’Reilly, 1998 • P. Coad, E. Yourdon “Analiza obiektowa”, Read Me, 1991 • H. E. Eriksson, M. Penker “UML Toolkit”, Wiley, 1998 47 © 2001 -2005 Bartosz Walter

Dynamiczne zachowanie obiektu Diagramy stanu obiektu czyli z życia (obiektów) wzięte 48 © 2001

Diagram stanu Modeluje cykl (fazy) życia obiektu – określa dozwolone stanu obiektu – definiuje dopuszczalne przejścia – określa zdarzenia, na które obiekt reaguje – określa akcje, jakie zachodzą podczas przejścia krojenie [nóż jest ostry] 49 © 2001 -2005 Bartosz Walter

Stany obiektu i przejścia Dopuszczalne stany – stany początkowy i końcowy – jeden ze stanów pośrednich Przejście jest opisane przez – zdarzenie, które wyzwala przejście – warunek, który weryfikuje dopuszczalność przejścia – akcję, która jest wykonywana w momencie przejścia 50 © 2001 -2005 Bartosz Walter

Stany obiektów w UML Reprezentacja stanu – nazwa – zmienne stanu – czynności Reprezentacja przejścia zdarzenie [warunek] / akcja ^ nowe-zdarzenie zapisz [operacja dozwolona] / ^dysk. zapisz() 51 © 2001 -2005 Bartosz Walter

Zdarzenia w UMLu Cztery rodzaje zdarzeń w UMLu – warunek staje się prawdziwy – odbiór sygnału od innego obiektu – wywołanie operacji przez inny obiekt – upływ określonego czasu – błędy (poza definicją UML) 52 © 2001 -2005 Bartosz Walter

Obsługa zdarzeń Wywołania operacji – wywołujący obiekt jest aktywny – wywoływany obiekt jest pasywny Obsługa sygnałów – wywoływany i wywołujący obiekt muszą być aktywne – sygnał jest obiektem ze stereotypem <<signal>> 53 © 2001 -2005 Bartosz Walter

Stany i podstany Stan może mieć podstany – typu or - aktywny jest jeden

Dynamiczne zachowanie obiektu Diagramy zachowania obiektu czyli z system w działaniu 55 © 2001

Modelowanie dynamiczne w UMLu Diagramy modelowania zachowania – czynności (activity diagram) odwzorowują akcje wykonywane na obiektach dokonują podziału odpowiedzialności za akcje – współpracy (collaboration diagram) wiążą współpracujące obiekty z uwzględnieniem kolejności pokazują zależności między obiektami słabo lub wcale wspierane przez Rational Rose! – sekwencji (sequence diagram) 56 © 2001 -2005 Bartosz Walter

Modelowanie dynamiczne w UMLu (cd. ) Diagram sekwencji – jak obiekty współdziałają ze sobą

Typy zdarzeń UML rozróżnia typy zdarzeń – synchroniczne, np. wywołania metod – asynchroniczne, np. sygnały – proste, np. przekazanie kontroli – synchroniczne z natychmiastowym powrotem 58 © 2001 -2005 Bartosz Walter

Istnienie obiektu Prostokąt na linii życia obiektu początek - aktywacja obiektu koniec - dezaktywacja obiektu usunięcie obiektu - znak X iteracja - prostokąt obejmujący zdarzenia rekursja - wywołanie własnych operacji 59 © 2001 -2005 Bartosz Walter

Fizyczna struktura systemu Podział na komponenty czyli małe jest piękne 60 © 2001 -2005

Pakiety Czym jest pakiet? – podsystemem – organizuje związane ze sobą elementy – jak

Pakiety (cd. ) Podział - i co dalej? – relacje między pakietami zależność, generalizacja, import elementów – widoczność elementów w pakiecie analogicznie do widoczności cech klas 62 © 2001 -2005 Bartosz Walter

Komponenty systemu – są fizyczną reprezentacją elementu modelu – relacja zależności komponentów – relacje ze znacznikiem {location} przyporządkowanie komponentów do zasobów – dostęp do usług poprzez interfejsy relacja wywołania (stereotyp <<calls>>) 63 © 2001 -2005 Bartosz Walter

Diagram rozmieszczenia Rozmieszczenie (deployment) fizyczna architektura systemu przyporządkowanie modułów do urządzeń zależności między zasobami

Zaawansowane elementy UML Stereotypy czyli szablony myślenia 65 © 2001 -2005 Bartosz Walter

Po co stereotypy? Odpowiednie dać rzeczy - słowo. . . brak elementu o precyzyjnym znaczeniu nie wiem, jak ci to wytłumaczyć. . . zbyt ogólne znaczenia istniejących elementów zegar 66 © 2001 -2005 Bartosz Walter

Nowe znaczenia Dawniej. . . dodajmy nowy element języka – dużo symboli, dużo znaczeń

Dlaczego stereotypy? Same zalety. . . potężny mechanizm rozszerzeń stosowane do wszystkich elementów dowolna

Jak wygląda stereotyp? Przedstawianie stereotypu sam łańcuch <<stereotyp>> w/przy elemencie ikona stereotypu 69 ©

Standardowe stereotypy UML ma kilkadziesiąt gotowych stereotypów <<actor>> ta klasa reprezentuje aktora <<import>> ta zależność definiuje import elementu <<signal>> ten obiekt jest sygnałem <<uses>> przypadek użycia korzysta z innego 70 © 2001 -2005 Bartosz Walter

Zaawansowane elementy UML Własności i znaczniki czyli jak być precyzyjnym 71 © 2001 -2005

Atrybuty elementów Jak opisać atrybut elementu modelu? . . . klasa ma status ‘draft’. . . ten atrybut nie może zostać zmieniony. . . Rodzaje atrybutów logiczne (true lub false) {abstract}, {invariant} o podanej wartości {status = ‘draft’} 72 © 2001 -2005 Bartosz Walter

Własności Własność (tagged value) definicja własności elementu w postaci wartość zapis łańcuch przy elemencie

Znaczniki Znacznik (tagged value) definicja własności elementu w postaci nazwa = wartość zapis {nazwa 1 = wartość1, nazwa 2 = wartość2} {nazwa 1} Są też znaczniki standardowe. . . np. abstract, precondition. . . 74 © 2001 -2005 Bartosz Walter

Ograniczenia Ograniczenie (constraint) jest własnością o wartości logicznej jest określone w pewnym języku Obiektowy Język Ograniczeń (OCL) propozycja formalnego języka dla UML bibliotekarz. wiek > 25 AND bibliotekarz. wiek < 65 75 © 2001 -2005 Bartosz Walter

Zaawansowane elementy UML Relacyjne bazy danych czyli łączenie światów 76 © 2001 -2005 Bartosz

Relacyjnie czy obiektowo? Relacyjne bazy danych dobrze rozwinięte szeroko stosowane wiele rozwiązań A UML?

RBD w UMLu Baza danych komponent z stereotypem <<database>> Schemat przestrzeń użytkownika w bazie

RBD w UMLu (cd. ) Tabela klasa ze stereotypem <<table>> Klucze podstawowe znacznik {PK}

RBD w UMLu (cd. ) Klucze obce znacznik {FK} na atrybucie ograniczenie integralnościowe jako operacja Ograniczenia operacje ze odpowiednim stereotypem, np. <<check>>, <<unique>> Wyzwalacze operacje ze stereotypem <<trigger>> 80 © 2001 -2005 Bartosz Walter

RBD w UMLu (cd. ) Relacje nie identyfikujące FK potomka jest podzbiorem PK rodzica relacja ze stereotypem <<not-identifying>> Relacje identyfikujące FK potomka jest równy PK rodzica potomek jest ściśle zależny od rodzica relacja ze stereotypem <<identifying>> 81 © 2001 -2005 Bartosz Walter

Podsumowanie Unifikacja postępuje czyli czy warto się przyłączyć? 82 © 2001 -2005 Bartosz Walter

Podsumowanie + Potęga metod obiektowych + UML jest de facto standardem + Wsparcie ze

Literatura • H. E. Eriksson, M. Penker “UML Toolkit”, Wiley, 1998 • S. S. Alhir “UML in a nutshell”, O’Reilly, 1998 • Rational Software “Rational Rose Documentation”, 2000 • http: //www. rational. com/uml/ 84 © 2001 -2005 Bartosz Walter