UML rozszerzenie Seminarium magisterskie

Slides:



Advertisements
Podobne prezentacje
Programowanie obiektowe
Advertisements

Związki w UML.
Projektowanie aplikacji równoległych Jarosław Kuchta.
Modelowanie aktywności
Diagramy stanów i diagramy aktywności
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Tomasz Andrejczuk Łukasz Razmuk gr. 620
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
Maciej I Stanisław Jedlińscy
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
Projektowanie Aplikacji Komputerowych
UML Unified Modeling Language
Co UML może zrobić dla Twojego projektu?
Tomasz Jabłoński Michał Ziach
Diagramy interakcji Jacek Górski gr
UML Zunifikowany język modelowania
Diagramy klas w języku UML
Diagram czynności (Activity Diagrams)
Projektowanie systemów informacyjnych
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie - wprowadzenie
Diagramy czynności.
Projektowanie dynamiki - diagramy interakcji
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Oskar Ośko Mateusz Skoczewski Michał Sułek
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Nadstruktura języka UML w wersji 2.2 Część V Wdrożenie (pakiet UML::Deployments)
Inżynieria Oprogramowania
Podstawy programowania
Automatyka i Robotyka Systemy czasu rzeczywistego Wykład 4.
DIAGRAMY UML.
Dziedziczenie Maciek Mięczakowski
Koncepcja procesu Zadanie i proces. Definicja procesu Process – to program w trakcie wykonywania; wykonanie procesu musi przebiegać w sposób sekwencyjny.
Związki w UML Do zrobienia jest: -Przerysować jak ktoś ma Visio te dwa diagramy tak żeby podmienić tylko nazwy a reszta Taka sama, -I dodać po jednym zdaniu.
Programowanie obiektowe – język C++
Diagramy aktywności Diagramy implementacyjne i pakietów.
Programowanie obiektowe 2013/2014
Modelowanie obiektowe Diagramy czynności
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Modelowanie obiektowe Diagramy sekwencji
Model dynamiczny (1) Diagramy interakcji.
Modelowanie obiektowe Diagramy klas
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Diagramy czynności/aktywności (Activity Diagrams)
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram przypadków użycia
Diagram klas Kluczowymi elementami są: klasy (class)
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
Modelowanie obiektowe - system zarządzania projektami.
Diagram czynności Diagram czynności (activity diagram) służy do modelowania dynamicznych aspektów systemu. Diagram czynności przedstawia sekwencyjne lub.
Diagram obiektów Diagram obiektów ukazuje elementy i związki z diagramu klas w ustalonej chwili. Diagram obiektów jest grafem złożonym z wierzchołków i.
Diagram przypadków użycia
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Diagramy przepływu danych
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Unified Modeling Language
E. Stemposz. Analiza dynamiczna w UML, Wykład 2, Slajd 1 Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML Wykład 2 Diagramy stanów Wykładowca:
Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML
Inżynieria systemów informacyjnych
T. 18. E Proces DGA - Działania (operatorka).
Diagramy interakcji Kamil Kuliczkowski.
Zapis prezentacji:

UML rozszerzenie Seminarium magisterskie „Zagadnienia programowania obiektowego” Marzena Szałas

Statyczna struktura systemu diagram klas; diagram obiektów; diagram komponentów; diagram wdrożenia.

Diagram klas

Diagram klas - notacja KLASA pole nazwy klasy (rzeczownik w liczbie pojedynczej). Nazwa klasy może być poprzedzona nazwą pakietu (wtedy nazwa ścieżkowa) pole atrybutów (opcjonalne). Można podać typ, wartość początkową oraz dostępność (czyli: ‘+’ – publiczny, ‘-’ – prywatny, ‘#’ – chroniony). pole operacji (opcjonalne) – czasownik lub wyrażenie opisujące pewne zachowanie danej klasy. Można dokładniej określić podając domyślne wartości wszystkich parametrów, a także (w przypadku funkcji) z typu przekazywanej wartości. ZWIĄZEK jest relacją między elementami; najważniejsze rodzaje to: zależność, uogólnienie i powiązanie.

ASOCJACJA/POWIĄZANIE Diagram klas – notacja ASOCJACJA/POWIĄZANIE nazwa krotność/liczebność kierunek nazwy nazwa roli reprezentuje związki między instancjami klas; posiada dwa punkty końcowe (często nazywane rolami), które mogą być opisane etykietą, która określa nazwę roli; może mieć nazwę. Nazwy powinny być nadawane tylko wtedy, gdy diagram jest dzięki temu bardziej zrozumiały. Można również podać kierunek odczytu; punkt końcowy ma krotność (określa ile obiektów może brać udział w danym związku). Przykładowa liczebność: 1, 0..1, 0..n, 1..n, 5; nawigowalność (jednokierunkowa lub dwukierunkowa). Asocjacji bez strzałek należy traktować jako dwukierunkowe bądź o nieznanej nawigowalności (kwestia umowna); klasy asocjacyjne pozwalają na dodanie atrybutów, operacji i innych elementów do asocjacji. Między dwoma obiektami połączonymi asocjacją może istnieć tylko jedna instancja klasy asocjacyjnej

AGRAGACJA I ZAWIERANIE Diagram klas - notacja AGRAGACJA I ZAWIERANIE agregacja to szczególny przypadek asocjacji, wyrażającym zależność całość–część między agregatem (całością) a składnikiem (częścią); nie istnieje powszechnie akceptowana definicja agregacji. UML zawiera agregację, ale nie mówi wiele na jej temat; zawieranie (inaczej: kompozycja, agregacja całkowita) jest silniejszą wersją agregacji; kompozycja: cykl życiowy składowej zawiera się w cyklu życiowym całości (czyli: części żyją i umierają wraz z całością) i składowa nie może być współdzielona (czyli: obiekt będący częścią mogą należeć wyłącznie do jednej całości); całość agregacja całkowita agregacja część

Diagram klas - notacja ZALEŻNOŚĆ związek użycia; należy używać kiedy chce się podkreślić, że jeden element używa drugiego; przedstawia się jako linia przerywana za grotem skierowanym na element, od którego coś zależy; może posiadać nazwę (gdy model ma wiele zależności – konieczne, wpp nie).

Diagram klas - notacja UOGÓLNIENIE klasa podstawowa uogólnienie relacja/związek między klasą ogólną a szczegółową („podklasa-nadklasa” lub „potomek-przodek”); potomek dziedziczy wszystkie właściwości przodka (w szczególności atrybuty i operacje). Może posiadać również własne cechy; operacja potomka mająca tę samą sygnaturę co operacja przodka jest ważniejsza – jest to POLIMORFIZM; przedstawiane jest jako linia ciągła zakończona zamkniętym, niewypełnionym grotem wskazującym przodka; jeśli klasa ma jednego przodka – dziedziczenie pojedyncze, wpp – wielodziedziczenie; używa się w celu przedstawienia dziedziczenia; może posiadać nazwę (gdy model ma wiele uogólnień – konieczne). liść

Diagram obiektów

Diagram obiektów - notacja przedstawia egzemplarze elementów z diagramu klas; obrazuje zbiór obiektów i ich związków w danej chwili; często nazywany jest diagramem instancji (przedstawia instancje klas a nie same klasy); zawiera na ogół: obiekty, wiązania, notatki, ograniczenia, pakiety, podsystemy, klasy. Diagram klas elementów struktury organizacyjnej Diagram obiektów pokazujący instancje elementów struktury organizacyjnej

Diagram komponentów

Diagram komponentów - notacja komponent – reprezentuje jeden fizyczny moduł kodu. Często jest to jeden pakiet, ale nie zawsze istnieje taka jednoznaczna odpowiedniość. Komponent musi posiadać nazwę, wyróżniającą go spośród pozostałych (gdy jest poprzedzony nazwą otaczającego pakietu, wtedy jest to nazwa ścieżkowa, wpp nazwa prosta). Można je grupować w pakiety. Dostępne są również wszystkie rozszerzenia, w tym: metki (definiujące nowe właściwości komponentu, np. określające numer wersji) oraz stereotypy (definiują nowe rodzaje komponentów. W UML zdefiniowane są następujące stereotypy komponentów: executable – określa komponent, który można wykonać na węźle; library – określa dynamiczną lub statyczną bibliotekę obiektów; table – określa komponent reprezentujący tabelę bazy danych; file – określa komponent reprezentujący dokument zawierający kod źródłowy lub dane; document – określa komponent reprezentujący dokument; zależność – występuje między komponentami. Pokazuje jak zmiany dotyczące jednego komponentu wpływają na inne. Można używać zarówno zależności komunikacyjnych, jak i kompilacyjnych;

Diagram komponentów - notacja interfejs nazwany zależność Komponent opatrzony stereotypem „database” interfejs bez nazwy komponent diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią - zależności) prowadzą od klienta pewnej informacji do jej dostawcy; dobrze skonstruowany komponent korzysta z innych komponentów wyłącznie za pośrednictwem ich interfejsów, co z założenia ułatwia przyszłe modyfikacje.

Diagram wdrożenia

Diagram wdrożenia pokazuje konfigurację elementów czasu wykonania: komponentów sprzętowych, czyli fizycznych jednostek posiadających co najmniej pamięć, a często i możliwości obliczeniowe; komponentów oprogramowania; związanych z nimi obiektów; jest grafem, gdzie wierzchołki (węzły) połączone są przez linie odwzorowujące połączenia komunikacyjne komponentów sprzętowych. Węzły, podobnie jak połączenia komunikacyjne, mogą być opatrzone stereotypami, np.: «CPU», «pamięć», «inne_urządzenie». Węzły przechowują wystąpienia obiektów i komponentów. Mogą brać udział w związkach generalizacji; zwany jest też diagramem instalacji;

Dynamiczne zachowania systemu diagram przypadków użycia; diagram interakcji: diagram sekwencji; diagram współdziałania; diagram czynności; diagram stanów.

Dynamiczne zachowania systemu Prosta reguła na wykorzystywanie diagramów dynamicznych w procesie modelowania zachowań: jeden obiekt, wiele przypadków użycia - diagramy stanu; wiele obiektów, jeden przypadek użycia - diagramy interakcji; wiele obiektów, wiele przypadków użycia - diagramy aktywności;

Diagram przypadków użycia

Diagram przypadków użycia - notacja Przypadek użycia – musi mieć nazwę unikalną, wyróżniającą go spośród innych przypadków. Jeśli jest tylko nazwa, wtedy mówimy o ‘nazwie prostej’, wpp o ‘nazwie ścieżkowej’ (nazwa jest poprzedzona nazwą pakietu: Nazwa_pakietu::nazwa). Problem: czy lepiej używać nazwę opisującą czynność (dodanie odbiorcy) czy polecenie (dodaj odbiorcę)? Aktor – musi mieć unikalną nazwę. Można zdefiniować zarówno ogólne rodzaje aktorów, jak i uszczegółowienia. Aktorem może być osoba, organizacja lub system komputerowy. Związek – pokazuje związek między przypadkiem użycia a aktorem Blok ponownego użycia - przedstawia fragment systemu, który jest używany przez kilka przypadków użycia. Może być oznaczony jako samodzielny przypadek użycia. weryfikacja klienta

Diagram przypadków użycia - notacja Relacja (typu «include» lub «extend») - pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. «include» - wskazuje na wspólny fragment wielu przypadków użycia. Wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane) «extend» - strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane) System obsługi klienta Nazwa systemu wraz z otoczeniem systemu - pokazuje granicę pomiędzy systemem a jego otoczeniem. wnętrze systemu

Diagram interakcji

Diagram interakcji opisują jak współpracują ze sobą grupy obiektów; zazwyczaj przedstawia zachowanie systemu dotyczące jednego przypadku użycia; przedstawia kilka przykładowych obiektów i komunikaty przez nie wymieniane w ramach przypadku użycia; istnieją dwa rodzaje: diagram sekwencji (przebiegu) – lepiej przedstawiają zależności czasowe, bardziej niż diagramy kolaboracji nadają się do modelowania systemów czasu rzeczywistego i złożonych scenariuszy; diagram współdziałania (współpracy, kolaboracji) – lepiej przedstawiają związki między obiektami biorącymi udział w realizacji danego przypadku użycia. Łatwiej też można tu odwzorować efekty oddziaływania na pojedynczy obiekt; niektóre narzędzia CASE potrafią wykorzystać te diagramy do generacji kodu;

Diagram sekwencji - notacja obiekty ośrodek sterowania C Z A S utworzenie linia życia powrót komunikat usunięcie

Diagram sekwencji - notacja na diagramach sekwencji możliwe jest (w przeciwieństwie do diagramów współdziałania) graficzne zaprezentowanie przepływu czasu, a nawet podawanie ograniczeń czasowych, czy też skali czasowej. Taka możliwość może mieć duże znaczenie dla opisu systemów czasu rzeczywistego; czasami przydaje się uwidocznienie wartości zwracanej przez komunikat, poprzez instrukcję przypisania (np.: ‘wMagazynie:=sprawdz()’). Umożliwia to późniejsze wykorzystanie tej wartości, np. jako argumentu dla innego komunikatu. Może też być wykorzystana do specyfikowania warunku czy iteracji; musi być wyspecyfikowane, kto jest odpowiedzialny za usuwanie obiektów;

Diagram współdziałania - notacja wiązanie obiekt stereotyp ścieżki komunikat kolejność współpracujące obiekty są połączone liniami, które odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja musi istnieć na diagramie klas; komunikaty mogą być numerowane, albo kolejnymi liczbami naturalnymi (jak na poprzednim diagramie), albo stosując tzw. numerację zagnieżdżoną. W obu przypadkach, z reguły, nie bierze się pod uwagę komunikatu wysyłanego od aktora; Obiekt, adresat komunikatu, musi go rozumieć, co oznacza, że klasa której jest wystąpieniem musi dostarczyć (definiować) tę operację;

WSPÓŁBIEŻNOŚĆ NA DIAGRAMACH INTERAKCJI Diagram interakcji WSPÓŁBIEŻNOŚĆ NA DIAGRAMACH INTERAKCJI dla interakcji sekwencyjnych nadawca komunikatu oczekuje na odpowiedź odbiorcy zawieszając własną działalność w trakcie oczekiwania. W danym momencie czasu działa tylko jeden obiekt i wysyłany może być tylko jeden komunikat. Takie systemy nazywane są też czasami proceduralnymi lub jednowątkowymi; notacja dla oznaczenia współbieżności: interakcja synchroniczna – nadawca zawiesza działanie, dopóki odbiorca nie zwróci sterowania. Można to oznaczyć wykorzystując symbol powrotu; powrót – nie jest komunikatem. Oznacza zakończenie komunikatu i przekazanie sterowania do nadawcy; interakcja płaska – nadawca komunikatu przekazuje sterowanie do odbiorcy oraz kończy własną działalność nie oczekując na odpowiedź; interakcja asynchroniczna – nadawca komunikatu nie oczekuje na odpowiedź odbiorcy, ale też i nie kończy własnej aktywności, co oznacza, że nadal przetwarza i może wysyłać komunikaty;

Diagram czynności

Diagram czynności kiedy używać: do analizowania przypadków użycia - gdy interesują nas bardziej operacje niezbędne do realizacji danego przypadku (czy też wzajemne zależności między tymi operacjami), a nie to, kto jest odpowiedzialny za ich przeprowadzenie; do zrozumienia interakcji zachodzących między przypadkami użycia; do modelowania przetwarzania wielowątkowego; kiedy nie używać: do pokazywania współpracy między obiektami w trakcie realizacji przypadku użycia – do tego bardziej nadają się diagramy interakcji; do pokazywania zachowań obiektów w trakcie ich życia, w tym celu powinno się wykorzystywać diagramy stanów;

Diagram czynności - notacja czynność (stan czynności) – stan działania lub działalności, wykonanie pewnego rzeczywistego procesu lub wykonywanie procedury programistycznej; przejście – z reguły oznacza zakończenie aktywności, może być opatrzone warunkiem, może też być oznaczone symbolem iteracji. Akcje opisujące przejścia powinny być raczej dołączone do którejś z aktywności; rozgałęzienie który może rozdzielać jedno przejście na kilka innych (opatrzonych warunkami) lub łączyć kilka alternatywnych przejść w jedno; rozwidlenie rozwidlenie lub złączenie– rozwidlenie ma jedno wejście i kilka wyjść. Kiedy jest odpalane wejście, to są wybierane równolegle wszystkie wyjścia. Czynności mogą zachodzić współbieżnie, ich kolejność jest nieważna złączenie stan początkowy stan końcowy

Diagram czynności - notacja TOR tor służą do dzielenia stanów czynności na grupy, z których każda reprezentuje jednostkę odpowiedzialną za przydzielone czynności; każdy tor ma nazwę, unikatową w obrębie jednego diagramu; na diagramie podzielonym na tory każda czynność należy do dokładnie jednego toru, ale przyjścia mogą przecinać granice torów;

Diagram stanu

Diagram stanu - notacja opisuje wszystkie możliwe stany, do których może przejść dany obiekt oraz jak zmienia się stan obiektu pod wpływem zdarzeń do niego docierających; stan obiektu trwa w czasie aż do momentu zajścia zdarzenia, które spowoduje zmianę aktualnego stanu na inny; stan może mieć nazwę, ale często jest charakteryzowany jedynie poprzez wewnętrzne operacje; STAN stan estry – każda akcja stowarzyszona ze zdarzeniem entry jest wykonywana przy każdym wejściu do stanu exit - akcja stowarzyszona ze zdarzeniem exit jest wykonywana przy każdym wyjściu ze stanu do/czynność – wykonanie czynności w trakcie, wskazanej za pomocą etykiety

Diagram stanu - notacja Różne rodzaje stanów: stan prosty – stan nie posiadający substruktury złożony sekwencyjnie – złożony z jednego lub więcej podstanów, z których tylko jeden jest aktywny, gdy aktywny jest stan złożony podzielony na dwa lub więcej współbieżnych podstanów; wszystkie podstany są jednocześnie aktywne, gdy aktywny jest stan złożony (jako całość) pseudostan służący do oznaczenia punktu startowego pseudostan służący do oznaczenia punktu finalnego

Diagram stanu - notacja PRZEJŚCIA przejście zewnętrzne przejście wewnętrzne zdarzenie [warunek] / akcja samoprzejście przejście automatyczne (wszystkie operacje wyspecyfikowane po słowach kluczowych ‘entry’, ‘exit’ i ‘do’ zostały ukończone) Rodzaje zdarzeń: otrzymanie przez obiekt synchronicznego żądania wykonania operacji – podstawowe; wygenerowane po upływie pewnego czasu, oznaczane słowem kluczowym ‘after’; wygenerowane po spełnieniu pewnego warunku, oznaczane słowem kluczowym ‘when’; otrzymania przez obiekt asynchronicznego żądania wykonania operacji – sygnał;

Diagram stanu - notacja STAN ZŁOŻONY SEKWENCYJNIE każdy z podstanów dziedziczy przejścia nadstanu; tylko jeden z podstanów może być aktywny w danym momencie.

Diagram stanu - notacja STAN ZŁOŻONY WSPÓŁBIEŻNIE rodzajem stanów złożonych są stany składające się ze współbieżnych podstanów; synchronizacja wewnętrzna: Wyjście ze stanu - w typowej sytuacji - następuje wtedy, gdy we wszystkich podstanach został osiągnięty ich stan końcowy Oba diagramy są równoważne synchronizacja zewnętrzna:

Organizacja modelu diagram pakietów; diagram podsystemów.

Diagram pakietów

Diagram pakietów stosowanie pakietów znacząco ułatwia zarządzanie przechowywaniem, konfiguracjami czy modyfikowaniem elementów systemu; dobrze przeprowadzony podział na pakiety może znacząco ułatwić zarządzanie procesem konstrukcji produktu programistycznego; pakiety są zestawami elementów danego modelu wraz z zachodzącymi pomiędzy nimi zależnościami; każdy element modelu musi być przypisany do jednego pakietu; dany model może być opisany przez zbiór pakietów; pakiety zawierają elementy tzw. wysokiego poziomu, takie jak np.: klasy i ich związki, maszyny stanu, grafy przypadków użycia, itp.; gdy pakiet jest niszczony, giną również wszystkie jego składniki;

Diagram pakietów pakiety mogą być zagnieżdżane; zależności pomiędzy pakietami (wynikające z zależności między elementami w nich zawartymi) są przedstawiane na diagramach pakietów w postaci strzałki z przerywaną linią. Strzałki zaznaczają przepływ informacji pomiędzy pakietami; pakiety mogą brać udział w związkach dziedziczenia; pakiety mogą być opatrywane stereotypami i listami własności etykietowanych; diagramy pakietów są istotne przede wszystkim dla dużych projektów, składających się z wielu jednostek funkcjonalnych (ze złożonymi zależnościami pomiędzy tymi jednostkami) oraz tworzonych przez grupę współpracujących osób;

Diagram pakietów - notacja każdy pakiet musi mieć nazwę, wyróżniającą go spośród pozostałych. Jeśli jest poprzedzona nazwą pakietu otaczającego ten pakiet, to jest to ‘nazwa ścieżkowa’, wpp ‘nazwa prosta’; widoczność składników pakietu: byt będący własnością danego pakietu jest publiczny, czyli dostępny dla zawartości dowolnego pakietu importującego ten pakiet (ozn. ‘+’); byt chroniony może być widziany jedynie przez potomków (ozn. ‘-’); byt prywatny nie może być w ogóle widziany na zewnątrz pakietu, w którym jest zadeklarowany (ozn. ‘#’);

Diagram pakietów - notacja wszystkie mechanizmy rozszerzenia (metki, stereotypy) dotyczą również pakietów. Pięć zdefiniowanych, standardowych stereotypów pakietów: facade – zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach; framework – określa pakiet składający się głównie ze wzorców; strub – określa pakiet będący pełnomocnikiem publicznej zawartości innego pakietu; subsystem – określa pakiet reprezentujący niezależną część całego modelowanego systemu; system – określa pakiet reprezentujący cały modelowany system; są zdefiniowane dwa rodzaje związków między pakietami: uogólnienia – służą do budowania rodzin pakietów; zależności ‘import’ i ‘access’ – używane do importowania do jednego pakietu bytów eksportowanych z innego pakietu;

Literatura oraz źródła diagramów G.Booch, J.Rumbaugh, I.Jacobson – „UML przewodnik użytkownika”; M. Fowler, K.Scott – „UML w kropelce”; E. Stemposz – wykłady z sieci; strony WWW.