Modelowanie z wykorzystaniem UML Bartosz Walter Bartosz.Walter@cs.put.poznan.pl

Plan dnia A1. Wprowadzenie do UML A2. Modelowanie struktury statycznej Bartosz Walter Plan dnia A1. Wprowadzenie do UML A2. Modelowanie struktury statycznej A3. Implementacja w Rational Rose B1. Modelowanie zachowań i podziału B2. Zaawansowane elementy UML B3. Implementacja w Rational Rose © 2001-2005 Bartosz Walter Modelowanie z wykorzystaniem UML

Obiektowe spojrzenie na świat Wprowadzenie do UML Obiektowe spojrzenie na świat czyli o modelowaniu, obiektach i języku © 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 © 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) © 2001-2005 Bartosz Walter

Istota modelowania Czym jest analiza? Sposoby zarządzania złożonością: „analiza to studium problemu przed podjęciem działania” Tom DeMarco, 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. © 2001-2005 Bartosz Walter

Cele modelowania divide et impera, czyli dekompozycja Bartosz Walter Cele modelowania divide et impera, czyli dekompozycja łatwiejsze wyobrażenie systemu specyfikacja struktury i zachowania dokumentacja decyzji podjętych w trakcie realizacji © 2001-2005 Bartosz Walter Modelowanie z wykorzystaniem UML

Cztery zasady modelowania Bartosz Walter Cztery zasady modelowania wybrany model determinuje rozwiązanie modelować można na różnych poziomach szczegółowości najlepsze modele odpowiadają rzeczywistości żaden model nie jest wystarczający © 2001-2005 Bartosz Walter Modelowanie z wykorzystaniem UML

W świecie obiektowym Elementy świata Komunikacja między nimi ś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! © 2001-2005 Bartosz Walter

Klasy i obiekty Cel: Obiekt: Klasa: 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 © 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 © 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! © 2001-2005 Bartosz Walter

UML w skrócie 9 typów diagramów - perspektyw mechanizm rozszerzeń 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) © 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) © 2001-2005 Bartosz Walter

Historia UML Dawno temu... Początki UML i Trzej Amigos 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

Historia UML (cd.) Rozwój UML Obecnie 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/ © 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 © 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 © 2001-2005 Bartosz Walter

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

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

Aktor, czyli działacz Aktor to ktoś (coś), kto (co) musi współdziałać z modelowanym systemem. Aktor © 2001-2005 Bartosz Walter

Aktor w UMLu Aktor w UMLu jest klasą (nie obiektem!) o nadanym stereotypie Actor. Można go oznaczać poprzez ikonę klasę ze stereotypem © 2001-2005 Bartosz Walter

Przypadek użycia 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... © 2001-2005 Bartosz Walter

Diagram use-case Definiuje ... i jest czytelny dla odbiorcy! 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! © 2001-2005 Bartosz Walter

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

Użycie funkcji Aktor używa funkcji (wykonuje funkcję) domyślny stereotyp <<communicates>> od użytkownika do funkcji © 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 © 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 © 2001-2005 Bartosz Walter

Statyczne zachowanie systemu Modelowanie struktury danych czyli o diagramach klas i obiektów © 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? © 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) © 2001-2005 Bartosz Walter

Operacje 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 © 2001-2005 Bartosz Walter

Atrybuty 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? © 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 © 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..* ? © 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 © 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 © 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 © 2001-2005 Bartosz Walter

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

Przykład diagramu klas © 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 © 2001-2005 Bartosz Walter

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

Case Study © 2001-2005 Bartosz Walter

Case Study © 2001-2005 Bartosz Walter

Case Study © 2001-2005 Bartosz Walter

Case Study © 2001-2005 Bartosz Walter

 Literatura G. Booch i in. "UML – przewodnik użytkownika", WNT 2001 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  © 2001-2005 Bartosz Walter Modelowanie z wykorzystaniem UML

Dynamiczne zachowanie obiektu Diagramy stanu obiektu czyli z życia (obiektów) wzięte © 2001-2005 Bartosz Walter

krojenie [nóż jest ostry] 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] © 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 © 2001-2005 Bartosz Walter

zapisz [operacja dozwolona] / ^dysk.zapisz() 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() © 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) © 2001-2005 Bartosz Walter

Obsługa zdarzeń Wywołania operacji Obsługa sygnałów 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>> © 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 © 2001-2005 Bartosz Walter

Dynamiczne zachowanie obiektu Diagramy zachowania obiektu czyli z system w działaniu © 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) © 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 © 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 © 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 © 2001-2005 Bartosz Walter

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

Pakiety Czym jest pakiet? podsystemem organizuje związane ze sobą elementy jak importować z obcych pakietów © 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 © 2001-2005 Bartosz Walter

Komponenty 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>>) © 2001-2005 Bartosz Walter

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

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

Po co stereotypy? zegar 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 © 2001-2005 Bartosz Walter

Nowe znaczenia Dawniej... UML dodajmy nowy element języka – dużo symboli, dużo znaczeń UML wykorzystajmy stary element o nowym znaczeniu + mało symboli, dużo znaczeń! © 2001-2005 Bartosz Walter

<<odkrycie>> Dlaczego stereotypy? Same zalety... potężny mechanizm rozszerzeń stosowane do wszystkich elementów dowolna precyzja znaczenia proste i czytelne diagramy <<odkrycie>> © 2001-2005 Bartosz Walter

Jak wygląda stereotyp? Przedstawianie stereotypu sam łańcuch <<stereotyp>> łańcuch <<stereotyp>> w/przy elemencie ikona stereotypu © 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 © 2001-2005 Bartosz Walter

Zaawansowane elementy UML Własności i znaczniki czyli jak być precyzyjnym © 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’} © 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 © 2001-2005 Bartosz Walter

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

bibliotekarz.wiek > 25 AND bibliotekarz.wiek < 65 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 © 2001-2005 Bartosz Walter

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

Relacyjnie czy obiektowo? Relacyjne bazy danych dobrze rozwinięte szeroko stosowane wiele rozwiązań Obiektowe bazy danych mało rozwiązań niepopularne A UML? © 2001-2005 Bartosz Walter

RBD w UMLu Baza danych Schemat komponent z stereotypem <<database>> Schemat przestrzeń użytkownika w bazie danych pakiet ze stereotypem <<schema>> © 2001-2005 Bartosz Walter

RBD w UMLu (cd.) Tabela Klucze podstawowe klasa ze stereotypem <<table>> Klucze podstawowe znacznik {PK} na atrybucie ograniczenie integralnościowe jako operacja © 2001-2005 Bartosz Walter

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

RBD w UMLu (cd.) Relacje nie identyfikujące Relacje 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>> © 2001-2005 Bartosz Walter

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

Podsumowanie + Potęga metod obiektowych + UML jest de facto standardem + Wsparcie ze strony producentów SW + Możliwości rozszerzeń © 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/  © 2001-2005 Bartosz Walter