Modelowanie z wykorzystaniem UML

Prezentacja na temat: "Modelowanie z wykorzystaniem UML"— Zapis prezentacji:

1 Modelowanie z wykorzystaniem UML
Bartosz Walter

2 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 © Bartosz Walter Modelowanie z wykorzystaniem UML

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

4 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 © Bartosz Walter

5 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) © Bartosz Walter

6 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. © Bartosz Walter

7 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 © Bartosz Walter Modelowanie z wykorzystaniem UML

8 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 © Bartosz Walter Modelowanie z wykorzystaniem UML

9 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! © Bartosz Walter

10 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 © Bartosz Walter

11 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 © Bartosz Walter

12 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! © Bartosz Walter

13 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) © Bartosz Walter

14 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) © Bartosz Walter

15 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 prace nad Metodą Zunifikowaną wersja 0.9 UML J. Rumbaugh G. Booch I. Jacobson © Bartosz Walter

16 Historia UML (cd.) Rozwój UML Obecnie I.1997 - wersja 1.0 UML
XI standaryzacja przez OMG Obecnie wersja 1.4 UML prace nad 2.0 UML © Bartosz Walter

17 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 © Bartosz Walter

18 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 © Bartosz Walter

19 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. © Bartosz Walter

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

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

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

23 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... © Bartosz Walter

24 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! © Bartosz Walter

25 Przykład diagramu use-case
© Bartosz Walter

26 Użycie funkcji Aktor używa funkcji (wykonuje funkcję)
domyślny stereotyp <<communicates>> od użytkownika do funkcji © Bartosz Walter

27 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 © Bartosz Walter

28 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 © Bartosz Walter

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

30 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? © Bartosz Walter

31 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) © Bartosz Walter

32 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 © Bartosz Walter

33 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? © Bartosz Walter

34 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 © Bartosz Walter

35 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..* ? © Bartosz Walter

36 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 © Bartosz Walter

37 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 © Bartosz Walter

38 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 © Bartosz Walter

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

40 Przykład diagramu klas
© Bartosz Walter

41 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 © Bartosz Walter

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

43 Case Study © Bartosz Walter

44 Case Study © Bartosz Walter

45 Case Study © Bartosz Walter

46 Case Study © Bartosz Walter

47  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  © Bartosz Walter Modelowanie z wykorzystaniem UML

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

49 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] © Bartosz Walter

50 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 © Bartosz Walter

51 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() © Bartosz Walter

52 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) © Bartosz Walter

53 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>> © Bartosz Walter

54 Stany i podstany Stan może mieć podstany
typu or - aktywny jest jeden podstan typu and - aktywnych może być kilka podstanów © Bartosz Walter

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

56 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) © Bartosz Walter

57 Modelowanie dynamiczne w UMLu (cd.)
Diagram sekwencji jak obiekty współdziałają ze sobą sposób wysyłania i odbioru zdarzeń składowa czasu © Bartosz Walter

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

59 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 © Bartosz Walter

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

61 Pakiety Czym jest pakiet? podsystemem
organizuje związane ze sobą elementy jak importować z obcych pakietów © Bartosz Walter

62 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 © Bartosz Walter

63 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>>) © Bartosz Walter

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

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

66 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 © Bartosz Walter

67 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ń! © Bartosz Walter

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

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

70 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 © Bartosz Walter

71 Zaawansowane elementy UML
Własności i znaczniki czyli jak być precyzyjnym © Bartosz Walter

72 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’} © Bartosz Walter

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

74 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... © Bartosz Walter

75 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 © Bartosz Walter

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

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

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

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

80 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>> © Bartosz Walter

81 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>> © Bartosz Walter

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

83 Podsumowanie + Potęga metod obiektowych + UML jest de facto standardem
+ Wsparcie ze strony producentów SW + Możliwości rozszerzeń © Bartosz Walter

84  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  © Bartosz Walter