Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Modelowanie z wykorzystaniem UML Bartosz Walter

Podobne prezentacje


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

1 Modelowanie z wykorzystaniem UML Bartosz Walter

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

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

4 © Bartosz Walter 4 Czym jest model? Świat rzeczywisty 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 Model

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

6 © Bartosz Walter 6 Istota modelowania Czym jest analiza? 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.

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

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

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

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

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

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

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

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

15 © Bartosz Walter 15 Historia UML Dawno temu... –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

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

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

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

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

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

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

22 © 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37 © Bartosz Walter 37 Zależność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

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

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

40 © Bartosz Walter 40 Przykład diagramu klas

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

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

43 © Bartosz Walter 43 Case Study

44 © Bartosz Walter 44 Case Study

45 © Bartosz Walter 45 Case Study

46 © Bartosz Walter 46 Case Study

47 © Bartosz Walter 47 LiteraturaLiteratura 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, OReilly, 1998 P. Coad, E. Yourdon Analiza obiektowa, Read Me, 1991 H. E. Eriksson, M. Penker UML Toolkit, Wiley, 1998

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

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

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

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

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

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

54 © 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

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

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

57 © 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

58 © 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

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

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

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

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

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

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

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

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

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

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

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

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

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

72 © 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}

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

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

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

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

77 © 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?

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

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

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

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

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

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

84 © Bartosz Walter 84 LiteraturaLiteratura H. E. Eriksson, M. Penker UML Toolkit, Wiley, 1998 S.S. Alhir UML in a nutshell, OReilly, 1998 Rational Software Rational Rose Documentation, 2000


Pobierz ppt "Modelowanie z wykorzystaniem UML Bartosz Walter"

Podobne prezentacje


Reklamy Google