Diagram klas Kluczowymi elementami są: klasy (class)

Slides:



Advertisements
Podobne prezentacje
C++ wykład 2 ( ) Klasy i obiekty.
Advertisements

Programowanie obiektowe
Związki w UML.
Modelowanie klas i obiektów
Projektowanie w cyklu życia oprogramowania
Wzorce.
Zaawansowane metody programowania – Wykład V
Kamil Łącki Dominik Strzelichowski
Implementacja asocjacji
Programowanie obiektowe w Javie
UML rozszerzenie Seminarium magisterskie
Co UML może zrobić dla Twojego projektu?
Bartosz Walter Prowadzący: Bartosz Walter
Katedra Mikroelektroniki i Technik Informatycznych Politechniki Łódzkiej UML- Unified Modeling Language Ujednolicony Język Modelowania UML jest standardowym.
Struktury.
Zasady zaliczenia Warunki uzyskania zaliczenia:
Pakiety i ATD 1 Definicja. Pakietem albo jednostką programową nazywamy grupę logicznie powiązanych elementów, które mogą być typami, podtypami, obiektami.
Unified Modeling Language Wykład 3 Diagram klas
DIAGRAMY KLAS i obiektów
Diagramy klas w języku UML
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Projektowanie - wprowadzenie
Wykład 4 Analiza i projektowanie obiektowe
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)
Nadstruktura języka UML w wersji 2.2
Inżynieria Oprogramowania
UML 2.x Robert Pająk.
Jakub Wołczko W obiektowym świecie… Jakub Wołczko
OMT - Model obiektów, cz.3.
Java – coś na temat Klas Piotr Rosik
Dziedziczenie Maciek Mięczakowski
Programowanie obiektowe Wykład 6 dr Dariusz Wardowski, Katedra Analizy Nieliniowej, WMiI UŁ 1/14 Dariusz Wardowski.
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++
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Prasek Aneta, Skiba Katarzyna. Funkcje stałe const to takie funkcje, które nie mogą modyfikować stanu obiektu. Oznacza to, że funkcja stała nie może zmieniać.
Modelowanie obiektowe Diagramy klas
Programowanie w języku C++
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram przypadków użycia
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
Projektowanie relacyjnych baz danych – diagramy związków encji
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.
Projekt modułu Nazwa całego projektu Nazwa modułu Imię i Nazwisko Inżynieria Oprogramowania II dzień, godzina rok akademicki W szablonie na niebiesko zamieszczone.
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Paweł Starzyk Obiektowe metody projektowania systemów
Programowanie Zaawansowane
Unified Modeling Language
Asocjacja,Kompozycja,Agregacja
ASP.NET Tworzenie i zarządzanie wyglądem aplikacji, tworzenie mapy witryny. Kontrolki nawigacyjne.
Inżynieria systemów informacyjnych
Programowanie Obiektowe – Wykład 6
T. 18. E Proces DGA - Działania (operatorka).
Programowanie Obiektowe – Wykład 2
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
Aplikacje i usługi internetowe
PGO - Projektowanie i implementacja pierwszych klas
PGO Dziedziczenie Michail Mokkas.
Zapis prezentacji:

Diagram klas Kluczowymi elementami są: klasy (class) związki (association) interfejsy (interface) Dodatkowo diagram może zwierać: notatki (note) ograniczenia (constraints) pakiety (packages)

Diagram klas Najczęściej spotykany w modelach obiektowych, Obrazuje statyczne aspekty systemu, Jeżeli diagram klas zawiera klasy aktywne, dotyczy tylko statycznych aspektów perspektywy projektowej, Wykorzystywany jest przy budowaniu systemów wykonywalnych z użyciem inżynierii do przodu i inżynierii wstecz.

Diagram klas Czym jest klasa? Klasa jest opisem zbioru obiektów, które mają takie same: atrybuty operacje związki znaczenia

Diagram klas Klasa w notacji UML Nazwa Atrybuty Operacje

Klasa Nazwa klasy (class name) musi wyróżniać klasę spośród innych. jeżeli jest to sama nazwa to jest to nazwa prosta. jeżeli nazwa poprzedzona jest nazwą pakietu to jest to nazwa ścieżkowa.

Klasa Atrybut klasy (attribute) to nazwana właściwość klasy. Określa zbiór wartości, jakie można przypisać do poszczególnych egzemplarzy tej klasy. Atrybuty

Klasa Dokładniejsze określenie atrybutu: dodanie typu dodanie wartości początkowej [ widoczność ] nazwa [ liczebność ] [ : typ ] [ = wartość początkowa ] [ {określenie właściwości} ]

Klasa Operacja klasy (opetarion) to implementacja usługi klasy. Wykonania usługi można zażądać od każdej instancji klasy. Operacje

Klasa Dokładniejsze określenie operacji: dodanie typu wartości zwracanej przez operację podanie parametrów, ich typów i wartości początkowych [ widoczność ] nazwa [ (lista parametrów) ] [ : typ wyniku ] [ {określenie właściwości} ]

Klasa Odpowiedzialność (responsibility) jest kontraktem lub zobowiązaniem klasy. Modelując klasy często zapisuje się jedynie zobowiązania klasy jakie musi ona wypełniać. W procesie dokładniejszego specyfikowania systemu zobowiązania tłumaczy się na zbiory atrybutów i operacji.

Klasa Odpowiedzialność klasy

Klasa Widoczność atrybutów i operacji określa kto może wywołać operacją, lub kto ma dostęp do kreślonego atrybutu. Typy widoczności: Public Protected Private Package

Klasa Widoczność Public + Każdy ma dostęp do elementów klasy (atrybutów i operacji) oznaczonych jako public.

Klasa Widoczność Protected # Atrybut lub operacja jest widoczna dla potomków klasy.

Klasa Widoczność Private - Atrybut lub operacja jest widoczna tylko dla innych elementów tej klasy.

Klasa Widoczność Package ~ Elementy klasy widoczne są jedynie dla klas zawierających się w tym samym pakiecie.

Klasa Dodatkowe właściwości klasy: abstrakcyjna klasa (abstract class) (nazwa klasy napisana kursywą) – klasa nie może mieć bezpośredniego egzemplarza elementy statyczne (static elements) – atrybuty lub operacje mogą być statyczne (nazwa podkreślona) – dostępne są również bez konkretnego egzemplarza klasy

Interfejs (Interface) Czym jest interfejs? Zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent. Interfejs wyznacza granicę między specyfikacją tego, co dana abstrakcja ma robić, a implementacją tego, jak to robi.

Interfejs Dobrze zbudowany interfejs charakteryzuje się tym, że wyraźnie oddzielone są wewnętrzne aspekty abstrakcji od zewnętrznych.

Interfejsy W UML 2.0 wprowadzono rozróżnienie pomiędzy interfejsami: interfejs dostarczany (provided interface) interfejs wymagany (required interface)

Interfejsy Każda klasa może być wykorzystywana na różne sposoby i może realizować różne interfejsy (różne usługi). Grupowanie usług klasy realizuje się za pomocą portów. Porty łączą implementację klasy ze środowiskiem, w którym istnieje. Komunikacja klasy odbywa się poprzez porty.

Interfejs dostarczany Interfejs dostarczany są to usługi które klasa implementuje. Klasa umożliwia innym elementom systemu korzystanie z obsługiwanych przez daną klasę usług. Dwie postacie interfejsu dostarczanego:

Interfejs dostarczany Nazwa interfejsu: prosta np.: IPisownia ścieżkowa np.: UsługiSieciowe::IRouter

Interfejs dostarczany Interfejs jest definicją usług oferowanych przez klasę lub komponent.

Interfejs wymagany Interfejs wymagany są to usługi, które inne klasy muszą dostarczyć w celu zapewnienia odpowiedniego funkcjonowania klasy w środowisku.

Interfejs wymagany Klasa wymaga tych interfejsów do poprawnej pracy. Komunikator internetowy nie udostępnia pełnej funkcjonalności użytkownikowi bez połączenie z Internetem.

Interfejs Interfejs wymagany i dostarczany

Związki Tylko niewielka liczba klas występuje samotnie. Większość klas wiąże się z innymi klasami następującymi związkami: zależność uogólnienie powiązanie

Związki Zależność to związek użycia. Zmiany dokonane w jednym elemencie mogą mieć wpływ na inny element. Z zależności należy korzystać kiedy chce się podkreślić, że jeden element używa drugiego.

Związki Uogólnienie to związek między elementem ogólnym a elementem szczególnym. Potomek może wystąpić wszędzie tam gdzie jest spodziewany przodek, ale nie na odwrót. Potomek dziedziczy wszystkie właściwości przodka (atrybuty i operacje).

Związki Uogólnienie

Związki Powiązanie – obiekty jednego elementu są połączone z obiektami innego. Powiązanie między dwoma klasami oznacza, że można przejść z obiektu jednej klasy do obiektu drugiej.

Związki Powiązanie może mieć: nazwę role (np.: pracownik, pracodawca) kierunek (również dwustronny) liczebność (multiplicity)

Związki Dodatkową funkcjonalnością powiązań jest agregacja (aggregation) i kompozycja (composition). Zwykłe powiązanie sprawia, że związane elementy są sobie równorzędne. W celu zaprezentowania związku „część-całość” należy użyć agregacji.

Związki Kompozycja, zwana również agregacją całkowitą, wprowadza dodatkowo zależność czasu życia klas oraz wyłączną własność. Części o nieustalonej liczebności mogą powstawać po utworzeniu całości, ale potem żyją i umierają razem z nią.

Klasy aktywne Do reprezentacji procesów lub wątków (które są źródłem przepływu sterowania) używa się klas aktywnych. Reprezentacja klasy aktywnej od klasy statycznej różni się pogrubioną ramką klasy.

Diagramy klas

Diagramy klas

Diagramy klas - Ćwiczenie Zbuduj diagram klas w oparciu o diagram przypadków użycia. Diagram przypadków użycia jest definicją wymagań funkcjonalnych systemu i nie musi mieć wspólnych cech z implementacją systemu. Prosta konwersja przypadek użycia → klasa zwykle jest błędna.