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 Bartosz.Walter@cs.put.poznan.pl

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

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

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

17 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 20 Statyczne zachowanie systemu Jak modelować funkcjonalność czyli o przypadkach użycia

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

22 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 25 Przykład diagramu use-case

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

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

30 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 39 Dziedziczenie (cd.) przykładowy diagram dziedziczenia

40 © 2001-2005 Bartosz Walter 40 Przykład diagramu klas

41 © 2001-2005 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 © 2001-2005 Bartosz Walter 42 Case Study Biblioteka: opis na załączonych kartkach

43 © 2001-2005 Bartosz Walter 43 Case Study

44 © 2001-2005 Bartosz Walter 44 Case Study

45 © 2001-2005 Bartosz Walter 45 Case Study

46 © 2001-2005 Bartosz Walter 46 Case Study

47 © 2001-2005 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 © 2001-2005 Bartosz Walter 48 Dynamiczne zachowanie obiektu Diagramy stanu obiektu czyli z życia (obiektów) wzięte

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

56 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 60 Fizyczna struktura systemu Podział na komponenty czyli małe jest piękne

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

62 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 64 Diagram rozmieszczenia Rozmieszczenie (deployment) fizyczna architektura systemu przyporządkowanie modułów do urządzeń zależności między zasobami

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

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

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

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

72 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 76 Zaawansowane elementy UML Relacyjne bazy danych czyli łączenie światów

77 © 2001-2005 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 © 2001-2005 Bartosz Walter 78 RBD w UMLu Baza danych komponent z stereotypem >Schemat przestrzeń użytkownika w bazie danych pakiet ze stereotypem >

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

80 © 2001-2005 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 © 2001-2005 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 © 2001-2005 Bartosz Walter 82 PodsumowaniePodsumowanie Unifikacja postępuje czyli czy warto się przyłączyć?

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

84 © 2001-2005 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 http://www.rational.com/uml/


Pobierz ppt "Modelowanie z wykorzystaniem UML Bartosz Walter"

Podobne prezentacje


Reklamy Google