1 Modelowanie z wykorzystaniem UMLBartosz Walter

2 Plan dnia A1. Wprowadzenie do UML A2. Modelowanie struktury statycznejBartosz 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 światWprowadzenie do UML Obiektowe spojrzenie na świat czyli o modelowaniu, obiektach i języku © Bartosz Walter

4 Czym jest model? Świat rzeczywisty Model System komputerowyModel 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ówElementy ś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 dekompozycjaBartosz 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 modelowaniaBartosz 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 Amigosróż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 UMLXI standaryzacja przez OMG Obecnie wersja 1.4 UML prace nad 2.0 UML © Bartosz Walter

17 Wsparcie ze strony przemysłu SWUML 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 oprogramowaniaUML 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 systemuJak 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 <> od użytkownika do funkcji © Bartosz Walter

27 Zależności między funkcjami (cd.)Funkcja uszczegóławia funkcję relacja dziedziczenia stereotyp <> 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 <> od funkcji wołającej do funkcji wołanej © Bartosz Walter

29 Statyczne zachowanie systemuModelowanie 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/obiekciecechy 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/obiektyposiadają 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 przodkauł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 kartkachCase 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 2001Bartosz 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 obiektuDiagramy 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ściaDopuszczalne 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 UMLuwarunek 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łówwywoł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 <> © Bartosz Walter

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

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

56 Modelowanie dynamiczne w UMLuDiagramy 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 obiektupoczą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 systemuPodział na komponenty czyli małe jest piękne © Bartosz Walter

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

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

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

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

65 Zaawansowane elementy UMLStereotypy 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 <>Dlaczego stereotypy? Same zalety... potężny mechanizm rozszerzeń stosowane do wszystkich elementów dowolna precyzja znaczenia proste i czytelne diagramy <> © Bartosz Walter

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

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

71 Zaawansowane elementy UMLWł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 < 65Ograniczenia 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 UMLRelacyjne 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 Schematkomponent z stereotypem <> Schemat przestrzeń użytkownika w bazie danych pakiet ze stereotypem <> © Bartosz Walter

79 RBD w UMLu (cd.) Tabela Klucze podstawoweklasa ze stereotypem <

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

81 RBD w UMLu (cd.) Relacje nie identyfikujące Relacje identyfikująceFK potomka jest podzbiorem PK rodzica relacja ze stereotypem <> Relacje identyfikujące FK potomka jest równy PK rodzica potomek jest ściśle zależny od rodzica relacja ze stereotypem <> © 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, 1998S.S. Alhir “UML in a nutshell”, O’Reilly, 1998 Rational Software “Rational Rose Documentation”, 2000  © Bartosz Walter