Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.

Podobne prezentacje


Prezentacja na temat: "Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników."— Zapis prezentacji:

1 Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników systemu stanowiący podstawę do stworzenia informatycznego systemu (kodu) Na podstawie diagramów klas bardzo prosto możemy generować kod (SQL, Java, C++ itd.) Diagramy klas są wykorzystywane przez analityków na etapie opracowywania koncepcji systemu jak i przez projektantów na etapie projektowania implementacji

2 Podstawy modelowania struktury
Klasy Obiekty Modelowanie związków pomiędzy klasami i obiektami Na samym początku odpowiedzieć należy na pytanie -czy IP jest nauką i czy powinna być wykładana na uczelni technicznej ? -czym zajmuje się IP -gdzie można stosować metody IP

3 Klasy Klasa jest najważniejszym blokiem konstrukcyjnym
Klasy służą do opanowania słownictwa systemu Klasy reprezentują byty istotne z pewnego punktu widzenia Klasy mogą pochodzić z dziedziny problemu Mogą też być związane z implementacją Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

4 Nazwy klas Klasa musi mieć przypisaną nazwę, która wyróżnia klasę spośród innych klas Nazwa może być poprzedzona nazwą (nazwami) pakietu (pakietów) i poprzedzona podwójnym dwukropkiem (nazwa ścieżkowa) Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

5 Operacje Operacja – implementacja pewnej usługi
Do wykonania operacji zdolny jest każdy obiekt klasy W modelu można określić także dziedzinę wartości parametrów i wartości domyślne oraz dziedzinę rezultatu Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

6 Odpowiedzialność Odpowiedzialność – jest to rodzaj kontraktu
Mówi się o zobowiązaniach klasy Klasa musi wypełnić swoje zobowiązania poprzez atrybuty i operacje Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

7 Relacja zależności Zależność – związek znaczeniowy pomiędzy klasami. Zmiany jednego elementu mogą mieć wpływ na znaczenie drugiego elementu Zależność może mieć nazwę Wybrane stereotypy używane w przypadku zależności pomiędzy klasami i obiektami: <<derive>> - źródło można wyznaczyć na podstawie celu <<friend>> - źródło ma szczególny dostęp do wnętrza celu <<refine>> - wskazuje, że źródło jest na doskonalszym poziomie abstrakcji <<use>> - źródło korzysta z publicznych składowych celu Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

8 Relacja powiązania Powiązanie – zbiór wiązań miedzy obiektami klasy.
Podstawowe właściwości: Liczność (zakres_od..zakres_do) Rola (rzeczownik znajdujący się na diagramie w pobliżu klasy) Nazwa (czasownik, lub rzeczownik odczasownikowy pośrodku linii łączącej klasy) Kierunek nawigacji (strzałka) – określa czy możliwe jest "przejście" od obiektu źródłowego do docelowego Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

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

10 Konceptualny diagram klas zawiera wyłącznie podstawowe elementy, cechując się przystępnością nazewnictwa klas, atrybutów i operacji. Implementacyjny diagram klas jest stopniowo wzbogacany o elementy opisu niezbędne dla prawidłowej specyfikacji modelu, takie jak typy danych, zobowiązania, widoczność, statyczność, klasy asocjacyjne, kwalifikacje, uogólnienia, zależności czy też realizacje.

11 Rodzaje diagramów klas
Diagramy klas, ze względu na znaczną liczbę elementów, jakie potencjalnie mogą na nich wystąpić, cechują się zróżnicowanym poziomem szczegółowości. Należy rozróżnić dwa poziomy tworzenia: poziom konceptualny, poziom implementacyjny.

12 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.

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

14 Klasy – wzorce obiektów
Klasa Opis grupy obiektów o jednolitym zbiorze atrybutów i sposobie zachowania Zawiera opis tworzenia obiektów klasy Klasę możemy nazwać „fabryką obiektów” Każda klasa posiada „wzorzec” (plany) dla tworzenia obiektów tej klasy. Każdy nowo tworzony obiekt klasy posiada osobną tożsamość, a także może mieć różne wartości atrybutów.

15 Model świata – związki klas obiektów
Obiekty w czasie swojego życia kontaktują się z innymi obiektami. Kontakty polegają na wzajemnym korzystaniu z udostępnianych usług. W trakcie modelowania określamy związki między klasami obiektów. Podstawowy „model świata” w podejściu obiektowym stanowi zatem zbiór klas obiektów wraz z odpowiednimi związkami między nimi.

16 wniesienie o rejestrację
własność Właściciel zarejestrowanie Rejestrator wykonanie czynności urzędowej dokonanie rejestracji Rejestracja

17

18 Metody obiektowe – jak z obiektów stworzyć system
Podstawowymi koncepcjami podejścia obiektowego są klasa i związki klas. Klasa jest także podstawowym pojęciem używanym we wszystkich językach programowania obiektowego. Model klas stworzony na etapie analizy znajduje swoje odzwierciedlenie w kodzie. Poprawna konstrukcja tego modelu jest zatem kluczowym czynnikiem powodzenia projektów. Podstawą każdej metody modelowania obiektowego jest technika budowy diagramów klas. Obok niej istnieją inne techniki pozwalające przy pomocy modeli opisać różne aspekty tworzonego systemu.

19 Diagram klas Klasa w notacji UML Nazwa Atrybuty Operacje

20 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.

21 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

22 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} ]

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

24 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} ]

25 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.

26 Klasa Odpowiedzialność klasy

27 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

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

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

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

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

32 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

33 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.

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

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

36 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.

37 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:

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

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

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

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

42 Interfejs Interfejs wymagany i dostarczany

43 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

44 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.

45 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).

46 Związki Uogólnienie

47 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.

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

49 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.

50 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ą.

51 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.

52 Diagramy klas

53 Diagramy klas

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


Pobierz ppt "Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników."

Podobne prezentacje


Reklamy Google