Diagramy UML 2.0. Diagram klas (class diagram) *.kls *.cld. + Zamówienie. + Hurtownia. + Naleznosc. + Platnosc. + Wplyw. + zamówienie 1..



Podobne dokumenty
Diagramy klas. WYKŁAD Piotr Ciskowski

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

Podstawy projektowania systemów komputerowych

Diagramy klas. dr Jarosław Skaruz

Modelowanie obiektowe

Rysunek 1: Przykłady graficznej prezentacji klas.

TECHNOLOGIE OBIEKTOWE. Wykład 3

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Inżynieria Oprogramowania. UML Schematy klas

UML w Visual Studio. Michał Ciećwierz

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Podstawy programowania III WYKŁAD 4

Projektowanie systemów multimedialnych

UML cz. II. UML cz. II 1/38

Diagram sekwencji. Komunikaty mogą być opisane w sposób sformalizowany. poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista)

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Bartosz Walter. InŜynieria oprogramowania. UML cz. I. Prowadzący: Bartosz Walter. UML cz. I 1

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Język UML w modelowaniu systemów informatycznych

Świat rzeczywisty i jego model

UML. dr inż. Marcin Pietroo

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

UML - zarys 2007/2008

UML. zastosowanie i projektowanie w języku UML

Diagramy przypadków użycia

Podstawy Programowania Obiektowego

Podstawy modelowania w języku UML

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Język UML w modelowaniu systemów informatycznych

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Język UML w modelowaniu systemów informatycznych

Dokumentacja do API Javy.

Laboratorium z przedmiotu: Inżynieria Oprogramowania INP

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Podstawy języka UML UML

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

MODELOWANIE OBIEKTOWE Z UML

Wzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski

Diagramy sekwencji. wymienianych między nimi

Podstawy języka UML2 w realnych projektach

Zalety projektowania obiektowego

UML [ Unified Modeling Language ]

MAS dr. Inż. Mariusz Trzaska

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Java - tablice, konstruktory, dziedziczenie i hermetyzacja

Diagramy czynności Na podstawie UML 2.0 Tutorial

Projekt z przedmiotu Projektowanie systemów teleinformatycznych

Programowanie obiektowe

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Cel drugiego wykładu

Klasy abstrakcyjne, interfejsy i polimorfizm

KLASA UCZEN Uczen imię, nazwisko, średnia konstruktor konstruktor Ustaw Wyswietl Lepszy Promowany

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Paweł Kurzawa, Delfina Kongo

Unified Modeling Language

Podstawy języka UML2 w realnych projektach

KatMPBSoft - 1 -

Piotr Kopalko Warszawa System obsługi teatru

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Język UML. dr inż. Piotr Szwed C3, pok

Diagramy stanów tworzenie modeli analizy i projektowania Na podstawie UML 2.0 Tutorial

Obszar statyczny dane dostępne w dowolnym momencie podczas pracy programu (wprowadzone słowem kluczowym static),

Projektowanie interakcji. Jarosław Kuchta

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

Materiały do zajęć VII

Informatyka I. Klasy i obiekty. Podstawy programowania obiektowego. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2018

Oprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria:

KLASA UCZEN Uczen imię, nazwisko, średnia konstruktor konstruktor Ustaw Wyswietl Lepszy Promowany

Definiowanie własnych klas

Język programowania Scala / Grzegorz Balcerek. Wyd. 2. Poznań, cop Spis treści

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Modelowanie i analiza systemów informatycznych Spis treści

Diagram maszyny stanowej - POJĘCIA

Metody Metody, parametry, zwracanie wartości

Modelowanie i analiza systemów informatycznych

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

UML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.

Języki programowania imperatywnego

UML w kropelce. czynność rozwinięcia 146 różnice między wersjami UML-a 175 wewnętrzna 130

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów

MAS dr. Inż. Mariusz Trzaska. Realizacja różnych modeli dziedziczenia w obiektowych językach programowania

Projektowanie bazy danych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

Technologie obiektowe

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Laboratorium z przedmiotu: Inżynieria Oprogramowania INEK Instrukcja 7

Obiekt klasy jest definiowany poprzez jej składniki. Składnikami są różne zmienne oraz funkcje. Składniki opisują rzeczywisty stan obiektu.

Charakterystyka oprogramowania obiektowego

Transkrypt:

Diagramy UML 2.0 Diagram klas (class diagram) + Hurtownia - nazwa : String - adres : String + hurtownia 1..1 + zamówienie 1..* + klient + Zamówienie - datazlozenia : int + zamówienie 1..1 + podst. platnosci *.kls *.cld + Platnosc + platnosc 1..* + Naleznosc - terminplatnosci : int - suma : float + Wplyw + zaksieguj()

Diagram klas Podstawowy diagram struktury logicznej systemu Przedstawia klasy występujące w systemie i statyczne relacje między nimi pozwala na sformalizowanie specyfikacji danych i metod w sposób związany z oprogramowaniem, ale dotyczący jego zewnętrznego opisu bez wchodzenia w szczegóły implementacyjne

Diagram klas Klasy i obiekty Klasę reprezentuje prostokąt, w którym zapisane są kolejno: Nazwa klasy Atrybuty klasy Operacje klasy + Klient - Pesel : int - Imie : String - Nazwisko : String - Adres : String + Zamawiaj() Cechy klasy są to informacje jakie klasa przechowuje. Przedstawiane są w postaci atrybutów klasy i relacji między klasami Operacje reprezentują usługi jakie klasa dostarcza

Diagram klas Klasy i obiekty Obiekt to instancja klasy + Kowalski:Klient - Pesel : int = 12345678901 - Imie : String = Jan - Nazwisko : String = Kowalski - Adres : String = Jakas 3/24 + Zamawiaj() Klasa jest więc opisem zbioru obiektów o takich samych atrybutach, związkach i znaczeniu.

Diagram klas Atrybuty klasy Pełne określenie atrybutu klasy posiada składnię: [widoczność]nazwa:typ[krotność]{ograniczenia}=wart. domyślna W UML-u wyróżniono 4 poziomy widoczności + publiczny widoczny z każdego miejsca systemu # chroniony widoczny wewnątrz klasy i jej podklas - prywatny widoczny tylko wewnątrz własnej klasy ~ publiczny wewnątrz pakietu widoczny wewnątrz własnego pakietu

Diagram klas Atrybuty klasy Pełne określenie atrybutu klasy posiada składnię: [widoczność]nazwa:typ[krotność]{ograniczenia}=wart. domyślna Krotność zapisywana jest najczęściej w postaci dolna granica..górna granica Przykłady: 1 dokładnie jeden 0..1 jeden lub wcale 1..* przynajmniej jeden * dowolna ilość

Diagram klas Atrybuty klasy Pełne określenie atrybutu klasy posiada składnię: [widoczność]nazwa:typ[krotność]{ograniczenia}=wart. domyślna Najczęściej stosowane ograniczenia to {ordered} elementy wewnątrz atrybutu są uporządkowane {unique} elementy wewnątrz atrybutu nie mogą się powtarzać {readonly} elementy wewnątrz atrybutu nie mogą być zmieniane {frozen} elementy wewnątrz atrybutu, po ustawieniu nie mogą być ponownie edytowane

Diagram klas Atrybuty klasy Atrybuty pochodne i statyczne + Paczka - Adres nadawcy : String - Adres odbiorcy : String - Rodzaj : String - Data wyslania : Date - Data dostarczenia : Date - Max termin dostarczenia : int - /Przetrzymana : boolean = (Data dostarczenia - Data wyslania)>max termin dostarczenia Atrybut pochodny jest zależny od innych atrybutów i może być wyliczony na ich podstawie. Oznaczany jest znakiem / Atrybut statyczny jest widoczny zarówno w klasie jak i w jej instancji podczas gdy inne atrybuty widoczne są wyłącznie w instancjach danej klasy. Oznaczany jest podkreśleniem nazwy.

Diagram klas Operacje klasy Operacje to procesy, które klasa potrafi wykonać Pełne określenie operacji posiada składnię: [widoczność] nazwa(parametr1, parametr2, ) :typ {ograniczenia} Parametry są zapisywane tak jak atrybuty z dodatkiem informacji o kierunku przekazania parametru kierunek nazwa typ[krotność]=wart. domyślna Dostępne kierunki in parametr wejściowy out parametr wyjściowy inout parametr wejściowo/wyjściowy return parametr zwracany przez metodę

Diagram klas Operacje klasy Operacje to procesy, które klasa potrafi wykonać Pełne określenie operacji posiada składnię: [widoczność] nazwa(parametr1, parametr2, ) :typ {ograniczenia} Tak samo jak w przypadku atrybutów istnieje możliwość zdefiniowania dodatkowych ograniczeń i informacji Podstawowym ograniczeniem jest {query} operacja jest zapytaniem. Nie powoduje zmian stanu obiektu Dodatkowo często oznacza się operacje zgłaszające wyjątki <<exception>>

Diagram klas Operacje klasy Operacje to procesy, które klasa potrafi wykonać Pełne określenie operacji posiada składnię: [widoczność] nazwa(parametr1, parametr2, ) :typ {ograniczenia} Operacje mogą mieć również przypisane warunki wstępny i końcowy Warunek wstępny określa w jakim stanie muszą znajdować się pewne elementy systemu by operacja wykonała się prawidłowo Np. pre: parametr1!= null Warunek końcowy określa oczekiwany stan elementu systemu po wykonaniu operacji Np. post: wynik!= null, wynik instanceof artykuły

Relacje - zależność Diagram klas Najsłabszym rodzajem relacji między klasami jest zależność Zmiana w jednej z klas wpływa jakoś na drugą. Zależność ta jest zwykle jednokierunkowa. Oznacza się ją przerywaną linią ze strzałką określającą kierunek relacji + Klasa 1 + Klasa 2 <<zależność>>

Relacje - zależność Diagram klas Do typowych zależności należą: <<call>> - operacje klasy E_1 wywołują operacje klasy E_2 <<create>> klasa E_1 tworzy instancje klasy E_2 <<instantiate>> obiekt E_1 jest instancją klasy 2 <<use>> - aby zaimplementować klasę E_1 niezbędna jest klasa E_2 + E_1 + E_2 <<zależność>>

Relacje - asocjacja Diagram klas Asocjacja reprezentuje czasowe powiązanie między obiektami dwóch klas. Obiekty te jednak są od siebie niezależne. Ich czas życia może być różny. Asocjacja jest równorzędnym do atrybutu sposobem zapisu cech klasy + Klient - Nazwisko : String - Imie : String - Adres : String - Identyfikator : int krotność + sklada 1..1 + {Od_kiedy<Do_kiedy} 0..* + asocjacja warunek + Rezerwacja - Nr_pokoju : int - Od_kiedy : Date - Do_kiedy : Date - Id_kl : int

Relacje - asocjacja Diagram klas Nawigowalność Określa jaka jest wiedza o sobie nawzajem obiektów uczestniczących w relacji Jedno i dwukierunkowa + Klient + Klient_1 + sklada 1..1 + {Od_kiedy<Do_kiedy} 0..* Klient zna swoje rezerwacje Rezerwacja nie ma informacji o kliencie + sklada 1..1 + {Od_kiedy<Do_kiedy} 0..* Możliwa jest nawigacja w obie strony + Rezerwacja + Rezerwacja_1

Relacje - asocjacja Klasa asocjacyjna Diagram klas Zawiera informacje dotyczące samej relacji asocjacji a nie przechowywane przez żaden z połączonych obiektów Jedno i dwukierunkowa + Klient + sklada 1..1 + {Od_kiedy<Do_kiedy} 0..* + Rezerwacja + zamowienie - Data_przyjecia : Date - Sposob_rez : String - potwierdzenie : boolean

Relacje - asocjacja Asocjacja kwalifikowana Diagram klas Wskazuje konkretny atrybut danej klasy zapewniający unikatowość relacji Atrybut ten jest jej kwalifikatorem + Klient + Rezerwacja Id_pokoju 1 + zamowienie *

Relacje - agregacja Diagram klas Agregacja reprezentuje relację całość część Część może należeć do kilku całości a jej czas życia jest od nich niezależny + Orkiestra + Karta muzyka - miejsce w orkiestrze : String - Nazwisko : String - Imie : String - Instrument : String - Data przyjecia : Date - Data zwolnienia : Date

Diagram klas Relacje - kompozycja kompozycja reprezentuje relację całość część Część należy tylko do jednej całości a jej czas życia jest od niej zależny. Jest jednym z komponentów z których składa się całość + Czasopismo - Tytul : String - Wydawnictwo : String - ISBN : String + Tom - Numer : String - Rocznik : int Usunięcie całości powoduje usunięcie wszystkich jego części

Diagram klas Relacje - uogólnienie Uogólnienie tworzy hierarchię klas Relacje wskazują klasę ogólną i klasy bardziej szczegółowe + magazyn + wyszukaj() + sortowanie() + magazyn podreczny + wyszukaj() + sortowanie() + magazyn surowcow + wyszukaj() + sortowanie() + magazyn produktow + wyszukaj() + sortowanie() Dziedziczenie jest jedną z technik uogólniania

Diagram klas Relacje - Klasyfikacja Reprezentuje związek między obiektem i klasami Obiekt może należeć jednocześnie do wielu klas - typów Ograniczenia przynależności do klas {disjoint} obiekt może należeć tylko do jednej klasy naraz {overlaping} obiekt może należeć do wielu klas, posiadać wiele typów {complete} prezentowana lista podklas jest kompletna, nie może powstać nowa podklasa {incomplete} mogą powstać nowe podklasy

Diagram klas Relacje - Klasyfikacja Reprezentuje związek między obiektem i klasami Obiekt może należeć jednocześnie do wielu klas - typów {disjoint}, {complete} {overlaping}, {incomplete} + ogolne + ksiazka + wydawnictwo + specjalizowane + czasopismo

Klasa abstrakcyjna Diagram klas Klasa abstrakcyjna reprezentuje wirtualny byt grupujący wspólną funkcjonalność kilku klas. Posiada ona sygnatury operacji (czyli deklaracje, że klasy tego typu będą akceptować takie komunikaty), ale nie definiuje ich implementacji. Klasa abstrakcyjna nie posiada własnych instancji obiektów. Na diagramie oznaczana jest kursywą w nazwie klasy lub słowem {abstract}

Diagram klas Uogólnienia hierarchia klas hhj Klasa najwyższa w hierarchii + Osoba {root} Klasa abstrakcyjna + Pracownik obslugi kina Żadna fizyczna osoba nie jest bezpośrednio pracownikiem obsługi kina + Pracownik dzialu informacji + Kasjer + Operator projektora Klasa najniższa w hierarchii + Kasjer biletowy {leaf} + Kasjer gastronomiczny {leaf}

Diagram klas Proces tworzenia diagramu klas - propozycja Zidentyfikowanie i nazwanie klas Połączenie klas z wykorzystaniem asocjacji Zidentyfikowanie i nazwanie atrybutów i operacji Określenie cech asocjacji (nazwa, role, nawigacja, liczebność, agregacja, kwalifikacja) Opracowanie innych rodzajów związków (uogólnień, zależności, realizacji) Wyspecyfikowanie atrybutów i operacji według składni Opracowanie diagramów obiektów

Diagram klas Przykład telefonia komórkowa + Biling + Karta SIM + Taryfa + nosnik pamieci 0..* + cennik 1..1 + zest. polaczen 0..* + numer 1..* + zbior dok. 1..1 + wlasciciel 1..1 + Korespondencja + komunikacja 0..* + Klient + wlasciciel 1..1 + Komorka + wlasciciel 1..1 + produkt 1..* + zbior dok. 1..1 + produkt 10..* + rozliczenie 0..* + punkt sprzedazy 1..* + Faktura + zestawienie 1..1 + Pozycja + SalonFirmowy + przedmiot sprz. 1..*

Diagram klas Przykład księgarnia wysyłkowa 1..* Książka -Autor : string -tytuł : string -wydawca : string -ISBN : String -datawydania : Date -cenanetto : Decimal -stawkavat : Byte +dodajpozycję() +usuńpozycję() +przekazpozycję() +obliczcenębrutto() +wyczyśćkoszyk() +wyszukaj() KartaKredytowa -typkarty : String -nrkarty : String -datawazności : Date -limit : Single +weryfikujdane() +obciąż() Zamówienie -nrzamówienia : String -datazamówienia : Date -formazapłaty : String -status : String 1..* 0..* +sporzadź() +ustaldatę() +zmieńformę() +zmieństatus() +wskazniezrealizowane() +wyliczwartość() 1 1 0..* 1 0..* 1 Klient #telefon : String #ulica : String #nrdomu : String #nrlokalu : String #kodpocztowy : String #miasto : String +aktualizuj() 0..* Użytkownik 1..3 -login : String -hasło : String +zaloguj() 0..* Faktura -nrfaktury : String -datawystawienia : Date -datapłatności : Date -Zapłacona : Boolean +sporzadź() +zaznaczpłatność() Dostawa -formadostarczenia : String -kosztnetto : Decimal -stawkavat : Byte +obliczkosztbrutto() +dodajkoszt() KlientFirmowy -nazwafirmy : String -NIP : String KlientIndywidualny -imię : String -nazwisko : String UżytkownikZaawansowany -poziomdostępu : Byte +zmieńdostęp()

Diagramy UML 2.0 Diagram sekwencji (sequence diagram) Opisuje sekwencje komunikatów wymienianych między obiektami Recepcjonista : Rezerwacja : BazaDanych : *.skw *.sd otwórzrezerwacje() sprawdzdostepnoscpokoi() 10/13 wprowadzdane() zamknij() dokonajrezerwacji()

Diagram sekwencji Diagramy sekwencji kładą nacisk na porządek w jakim dzieją się rzeczy Służą przede wszystkim do pokazywania interakcji między poszczególnymi elementami systemu Pokazują czas życia obiektów w stosunku do innych współuczestniczących w obsłudze danego zadania Z reguły pokazują jeden scenariusz, nie wszystkie możliwe

Diagram sekwencji Elementy diagramu Obiekt Okno_logowania Reprezentuje obiekt w systemie lub jeden z jego komponentów Czas Linia życia. Pokazuje czas istnienia danego obiektu.

Diagram sekwencji Elementy diagramu Aktywacja Okno_logowania Obszar aktywacji. Reprezentuje czas, w którym obiekt jest aktywny (wykonuje jakieś zadanie) Znacznik zerwania. Pokazuje jawnie chwilę w której dany obiekt przestaje istnieć

Diagram sekwencji Elementy diagramu Okno_logowania Komunikat Pokazuje przepływ sterowania (i informacji) między poszczególnymi obiektami Skrypt_logowania Sprawdź_logowanie Istnieje kilka rodzajów komunikatów

Diagram sekwencji Elementy diagramu Komunikat Komunikat prosty Komunikat synchroniczny Komunikat asynchroniczny Komunikat zwrotny Pełne przekazanie sterowania do drugiej instancji Wstrzymanie operacji do czasu uzyskania odpowiedzi Kontynuowanie operacji bez oczekiwania na odpowiedź Powrót z wywołania podprogramu

Diagram sekwencji Przepływy komunikatów Sprzedawca Zamówienie Artykuł pobierzwartość cena pobierzadres Przepływ zagnieżdżony

Diagram sekwencji Komunikaty mogą być opisane w sposób sformalizowany poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista) Poprz lista komunikatów poprzedzających Warunek warunek wysłania komunikatu Iter ilość powtórzeń komunikatu Nr sekw numer określający kolejność komunikatu Wynik nazwa zmiennej zwracanej Operacja nazwa wywoływanej operacji wraz z parametrami

Diagram sekwencji Komunikaty mogą być opisane w sposób sformalizowany poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista) Przykłady komunikatów przesuń(1,2) wyn1:=przesuń(5,5), *[1..5]: wyn1 := przesuń(5,7) [z>0]: wyn1 := przesuń(5,7), A3,B4 / [x<0] *[1..4] C3.1: wyn2 := pobierzlokację(wyn1) [dostęp do bazy] *[Dla każdego rekordu] 6: DaneWyj:=Formatuj(DaneWej,Format) [drukarka zajęta] zapisz_do_kolejki(wydruk)

Diagram sekwencji Przepływy komunikatów Obiekt1 Obiekt2 Warunki pozwalają na rozdzielenie komunikatów i wprowadzenie alternatywnych linii życia obiektów [x>0]komunikat1 [x<=0]komunikat2 Alternatywna linia życia obiektu 2

Diagram sekwencji Przepływy komunikatów Obiekt1 Obiekt3 Obiekt2 Możliwe jest również alternatywne wykorzystywanie dodatkowych obiektów [x>0]komunikat1 [x<=0]komunikat2 Komunikat3 Obiekt wykorzystywany tylko w przypadku x<=0

CDN Diagram sekwencji