Modelowanie z wykorzystaniem UML Bartosz Walter Bartosz Waltercs
Modelowanie z wykorzystaniem UML Bartosz Walter Bartosz. Walter@cs. put. poznan. pl © 2001 -2005 Bartosz Walter
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 © 2001 -2005 Bartosz Walter
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 Bartosz Walter
Aktor, czyli działacz Aktor to ktoś (coś), kto (co) musi współdziałać z modelowanym systemem. Aktor 21 © 2001 -2005 Bartosz Walter
Aktor w UMLu jest klasą (nie obiektem!) o nadanym stereotypie Actor. Można go oznaczać poprzez – ikonę – klasę ze stereotypem 22 © 2001 -2005 Bartosz Walter
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 do funkcji 26 © 2001 -2005 Bartosz Walter
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 © 2001 -2005 Bartosz Walter
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 -2005 Bartosz Walter
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 podstan – typu and - aktywnych może być kilka podstanów 54 © 2001 -2005 Bartosz Walter
Dynamiczne zachowanie obiektu Diagramy zachowania obiektu czyli z system w działaniu 55 © 2001 -2005 Bartosz Walter
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ą – sposób wysyłania i odbioru zdarzeń – składowa czasu 57 © 2001 -2005 Bartosz Walter
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 Bartosz Walter
Pakiety Czym jest pakiet? – podsystemem – organizuje związane ze sobą elementy – jak importować z obcych pakietów 61 © 2001 -2005 Bartosz Walter
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 64 © 2001 -2005 Bartosz Walter
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ń UML wykorzystajmy stary element o nowym znaczeniu + mało symboli, dużo znaczeń! 67 © 2001 -2005 Bartosz Walter
Dlaczego stereotypy? Same zalety. . . potężny mechanizm rozszerzeń stosowane do wszystkich elementów dowolna precyzja znaczenia proste i czytelne diagramy <<odkrycie>> 68 © 2001 -2005 Bartosz Walter
Jak wygląda stereotyp? Przedstawianie stereotypu sam łańcuch <<stereotyp>> w/przy elemencie ikona stereotypu 69 © 2001 -2005 Bartosz Walter
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 Bartosz Walter
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 komentarz 73 © 2001 -2005 Bartosz Walter
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 Walter
Relacyjnie czy obiektowo? Relacyjne bazy danych dobrze rozwinięte szeroko stosowane wiele rozwiązań A UML? Obiektowe bazy danych mało rozwiązań niepopularne 77 © 2001 -2005 Bartosz Walter
RBD w UMLu Baza danych komponent z stereotypem <<database>> Schemat przestrzeń użytkownika w bazie danych pakiet ze stereotypem <<schema>> 78 © 2001 -2005 Bartosz Walter
RBD w UMLu (cd. ) Tabela klasa ze stereotypem <<table>> Klucze podstawowe znacznik {PK} na atrybucie ograniczenie integralnościowe jako operacja 79 © 2001 -2005 Bartosz Walter
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 strony producentów SW + Możliwości rozszerzeń 83 © 2001 -2005 Bartosz Walter
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
- Slides: 84