Diagramy klas

(1)

Diagramy klas

Halina Tańska

(2)

Unified Modeling Language

Diagramy struktury:

• diagram klas (class diagram)

• diagram obiektów (object diagram)

• diagram komponentów (component diagram)

• diagram pakietów (package diagram)

• diagram wdrożenia (deployment diagram)

• zbiorowy diagram

komponentów (composite structure diagram)

Diagramy dynamiki:

• diagram przypadków użycia (use case diagram)

• diagram czynności (activity diagram)

• diagram maszyny stanów (state machine diagram)

• diagram sekwencji (sequence diagram)

• diagram komunikacji

(communication diagram)

• diagram przeglądu

współdziałania (interaction overview diagram)

• diagram czasowy (timing diagram)

(3)

Diagram klas

• Świat, postrzegany z perspektywy obiektowej, składa się z wielu niezależnych obiektów, które działają według

pewnych reguł i współpracują ze sobą dla osiągnięcia założonego celu.

• Podstawowym sposobem budowania i porządkowania modelu świata jest klasyfikacja, czyli odnajdywanie klas (zbiorów) obiektów podobnych, zbudowanych zgodnie z tym samym wzorcem i podejmujących takie same

działania.

• Poznawanie świata przez klasyfikowanie postrzeganych obiektów jest fundamentalnym wzorcem pozyskiwania i porządkowania wiedzy przez człowieka.

(4)

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żna 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

(5)

Diagram klas

Kluczowymi elementami są:

• klasy (class)

• związki (association)

• interfejsy (interface)

Dodatkowo diagram może zwierać:

• notatki (note)

• ograniczenia (constraints)

• pakiety (packages)

(6)

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.

(7)

Diagram klas

Klasa jest opisem zbioru obiektów, które mają takie same:

• atrybuty

• operacje

• związki

• znaczenia

(8)

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żna 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.

1/4

(9)

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.

2/4

(10)

• Dowolny obiekt jest instancją abstrakcyjnego pojęcia, jakim jest klasa (ang. class) obiektu.

• Podstawę identyfikacji klasy stanowią grupy obiektów charakteryzujące się:

– identyczną strukturą danych tj. takimi samymi atrybutami;

– identycznym zachowaniem tj. takimi samymi operacjami;

– identycznymi związkami;

– identycznym znaczeniem w określonym kontekście.

Model świata – związki klas obiektów^3/4

(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)

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.

(13)

Diagram klas - definicja

• Diagram klas obrazuje pewien zbiór klas, interfejsów i kooperacji oraz związki między nimi.

• Jest to graf złożony z wierzchołków (klas, interfejsów, kooperacji) i łuków (reprezentowanych przez relacje)

• Diagram klas stanowi opis statyki systemu, który uwypukla związki między klasami.

• Najsilniej prezentuje strukturę systemu i jest podstawą dla jego konstrukcji.

• Diagram klas służy do zobrazowania statycznych

aspektów perspektywy projektowej, w której bierze się pod uwagę wymagania funkcjonalne systemu – usługi, jakie system powinien udostępniać swoim użytkownikom.

(14)

Etapy tworzenia diagramu klas

1) zidentyfikowanie i nazwanie klas;

2) opcjonalnie określenie zobowiązań klas;

3) połączenie poszczególnych klas z wykorzystaniem związków asocjacji;

4) zidentyfikowanie oraz nazwanie atrybutów i operacji;

5) wyspecyfikowanie asocjacji z użyciem wszystkich jej cech (nazwy, ról, nawigacji, liczebności, agregacji, kwalifikacji);

6) opracowanie innych rodzajów związków, tj. uogólnień, zależności i realizacji;

7) pełne, precyzyjne wyspecyfikowanie atrybutów i operacji;

8) opcjonalnie opracowanie diagramów obiektów.

(15)

dokonanie rejestracji zarejestrowanie

Właściciel własność wniesienie o

rejestrację

Rejestrator

wykonanie czynności urzędowej

Rejestracja

Pojazd

Klasy obiektów i związki klas obiektów - przykład

(16)

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.

(17)

Klasa obiektu Uczelnia w notacji UML

Nazwa

Atrybuty

Operacje

(18)

Klasa - nazwa

Nazwa klasy (class name)

musi wyróżniać klasę spośród innych

jeżeli nazwa poprzedzona jest nazwą pakietu to jest to nazwa ścieżkowa

jeżeli używamy tylko nazwę klasy obiektów to jest to nazwa prosta

1/5

(19)

Klasa - nazwa

Reprezentacja klas na diagramach

Możliwe kombinacje graficznej prezentacji klas:

sama nazwa klasy;

nazwa klasy z zestawem atrybutów;

nazwa klasy z zestawem operacji;

nazwa klasy z zestawem atrybutów i operacji.

2/5

(20)

W związku z różnorodnością możliwych sposobów specyfikowania klas możliwe jest zastosowanie:

 sama nazwa klasy umieszczona w jednosekcyjnym bloku oznacza, że sekcje atrybutów i operacji zostały

wyspecyfikowane, lecz nie w sposób jawny zamieszczone na diagramach klas;

 alternatywnie, klasę przedstawia się jako blok złożony z trzech sekcji z nazwą w pierwszej sekcji i

niewyspecyfikowanymi atrybutami i operacjami;

 jeśli liczba atrybutów lub operacji jest większa, to ich wyliczanie w odpowiednich sekcjach można przerwać

wielokropkiem, co należy interpretować, jako przypisanie klasie jeszcze innych atrybutów i operacji –

niewymienionych bezpośrednio w specyfikacji.

Klasa - nazwa ^3/5

(21)

Student

Oblicz średnia(): real Nr indeksu: integer Nazwisko: string Oceny: string

Student

Oblicz średnia() Nr indeksu

Nazwisko Oceny

Student Nr indeksu Nazwisko Oceny

Student

Klasa obiektu Student w notacji UML Różne poziomy szczegółowości

Student

Oblicz średnia() 4/5

(22)

Nazwa klasy - podsumowanie

• Głównym zadaniem nazwy klasy jest opisanie obiektów, które ona grupuje.

• Przyjmuje się, że nazwa klasy powinna określać pojedynczy obiekt tej klasy, w związku z tym nazwa klasy jest

rzeczownikiem w liczbie pojedynczej.

• Przykładowo: Osoba, Rachunek, Książka, Pojazd, Wypożyczenie to nazwy klas.

5/5

(23)

Diagram klas

• atrybuty

• operacje

• związki

• znaczenia

(24)

Klasa – atrybuty

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

(25)

Klasa – atrybuty

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

(26)

Diagram klas

• atrybuty

• operacje

• związki

• znaczenia

(27)

Klasa – operacje

Operacja klasy (operation) to implementacja usługi klasy.

Wykonania usługi można zażądać od każdej instancji klasy.

Operacje

(28)

Klasa – operacje

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

(29)

Klasa – operacje

• lista parametrów: definiuje listę parametrów formalnych metody;

• składnia pojedynczego parametru jest następująca:

rodzaj nazwa_parametru : typ = wartość_początkowa

gdzie rodzaj określa sposób, w jaki metoda korzysta z danego argumentu:

in: metoda może czytać wartość parametru, ale nie może jej zmieniać

out: metoda może zmieniać wartość parametru, ale nie może jej czytać;

inout: metoda może zarówno czytać, jak i zmieniać wartość parametru.

(30)

Klasa – zobowiązania

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.

(31)

Klasa – zobowiązania

(32)

class Logical View

Kurs

Wykład

Student

Pracow nik Osoba

Profesor +poprzedni

0..1

+następny

*

1..*

+zapisany na 1..*

*

+prowadzący 1

Przykład Kursy – poziom konceptualny

(33)

Diagram klas

• atrybuty

• operacje

• związki

• znaczenia

widoczność

(34)

Klasa – widoczność

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

(35)

Widoczność składowych klasy

publiczny + Obiekty wszystkich klas mają dostęp do atrybutu lub operacji

prywatny - Dostęp jedynie w obrębie danej klasy

chroniony # Dostęp jedynie dla klas dziedziczących z danej klasy

pakietowy ~ Dostęp tylko dla składowych pakietu, do którego klasa należy

Nazwa klasy + atrybut1:

- atrybut2:

# atrybut3:

~ atrybut4:

+ operacja1()

# operacja2() - operacja3()

~ operacja4()

(36)

Widoczność Public +

Każdy ma dostęp do elementów klasy

(atrybutów i operacji) oznaczonych jako public.

(37)

Widoczność Protected #

Atrybut lub operacja jest widoczna dla potomków klasy.

(38)

Widoczność Private -

Atrybut lub operacja jest widoczna tylko dla innych elementów tej klasy.

(39)

Widoczność Package ~

Elementy klasy widoczne są jedynie dla klas zawierających się w tym samym pakiecie.

(40)

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

(41)

Diagram klas

• klasy (class)

(42)

Interfejs (Interface)

Interfejs jest to zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent

Interfejsy służą do prezentowania komunikacji pomiędzy komponentami

Interfejs wyznacza granicę między specyfikacją tego, co dana abstrakcja ma robić, a implementacją tego, jak to robi

Dobrze zbudowany interfejs charakteryzuje się tym, że wyraźnie oddzielone są

wewnętrzne aspekty abstrakcji od zewnętrznych

1/10

(43)

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.

2/10

(44)

Interfejsy

W UML 2.0 wprowadzono rozróżnienie pomiędzy interfejsami:

interfejs dostarczany (provided interface)

interfejs wymagany (required interface)

3/10

(45)

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:

4/10

(46)

Nazwa interfejsu:

• prosta

np.: IPisownia

• ścieżkowa

np.: UsługiSieciowe::IRouter

5/10

(47)

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

6/10

(48)

Interfejs wymagany

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

środowisku.

7/10

(49)

Interfejs wymagany - przykład

Klasa wymaga tych interfejsów do poprawnej pracy.

Komunikator internetowy nie udostępnia pełnej funkcjonalności użytkownikowi bez połączenia z Internetem.

8/10

(50)

Interfejs

Interfejs wymagany i dostarczany - przykłady

protokółEgzaminacyjny IOceny

OCENA

9/10

(51)

Interfejs (Interface) - podsumowanie

Interfejs jest to zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent

Interfejsy służą do prezentowania komunikacji pomiędzy komponentami

Interfejs wyznacza granicę między specyfikacją tego, co dana abstrakcja ma robić, a implementacją tego, jak to robi

Dobrze zbudowany interfejs charakteryzuje się tym, że wyraźnie oddzielone są

wewnętrzne aspekty abstrakcji od zewnętrznych

10/10

(52)

Diagram klas

• klasy (class)

(53)

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

(54)

Związki - zależność

Zależność (dependency) to związek pomiędzy dwoma elementami modelowania – 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.

Klasa docelowa Klasa źródłowa

(55)

Laboratorium StanowiskoKomputerowe

<<use>>

Typowe zastosowanie zależności typu <<use>>

do prawidłowego działania klasy Laboratorium jest potrzebne użycie klasy StanowiskoKomputerowe

Związki – zależność - przykład

(56)

Wybrane typy związku zależności

Słowo kluczowe Znaczenie

<<call>> Źródło wywołuje cel

<<create>> Źródło tworzy obiekt docelowy

<<deriver>> Źródło można wyznaczyć na podstawie celu

<<import>> Zawartość publiczna celu zostaje dołączona do obszaru nazw źródła

<<instance>> Źródło tworzy egzemplarz klasy

<<permit>> Cel pozwala źródłu na dostęp do swoich cech prywatnych

<<realize>> Źródło jest implementacją specyfikacji lub interfejsem definiowanym przez cel

<<refine>> Źródło jest na doskonalszym poziomie abstrakcji niż cel

<<substitute>> Źródło jest substytutem celu

<<trace>> Cel jest historycznie przodkiem źródła

<<use>> Źródło wymaga celu do swojego funkcjonowania

(57)

Wybrane typy związku zależności

Słowo kluczowe Znaczenie

<<call>> Źródło wywołuje cel

<<create>> Źródło tworzy obiekt docelowy

<<deriver>> Źródło można wyznaczyć na podstawie celu

<<import>> Zawartość publiczna celu zostaje dołączona do obszaru nazw źródła

<<instance>> Źródło tworzy egzemplarz klasy

<<permit>> Cel pozwala źródłu na dostęp do swoich cech prywatnych

<<realize>> Źródło jest implementacją specyfikacji lub interfejsem definiowanym przez cel

<<refine>> Źródło jest na doskonalszym poziomie abstrakcji niż cel

<<substitute>> Źródło jest substytutem celu

<<trace>> Cel jest historycznie przodkiem źródła

<<use>> Źródło wymaga celu do swojego funkcjonowania

(58)

Związki

• zależność

• uogólnienie

• powiązanie

<<use>>

(59)

Związki - uogólnienie

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

(60)

Związki - uogólnienie

Dziekan

Wykładowca

(61)

class Domain Obj ects

Wymóg - Nośnik:

+ sprawdź_poprawność () : void + publikuj() : void

System - Platforma:

+ sprawdź_poprawność () : void + wdrażaj() : void

Produkty_pracy - Opis:

- Procent_ukończenia:

+ sprawdź_poprawność () : void

Związki – uogólnienie - generalizacja

(62)

Związki

• zależność

• uogólnienie

• powiązanie

<<use>>

(63)

Związki – powiązanie (asocjacja)

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.

(64)

Związki – powiązanie (asocjacja)

Powiązanie może mieć:

• nazwę

• role (np.: pracownik, pracodawca)

• kierunek (również dwustronny)

• liczebność (multiplicity)

(65)

Asocjacja – związek strukturalny

Asocjacja opisuje związek strukturalny między elementami (klasami).

Wskazuje, że obiekty jednego elementu są połączone z obiektami drugiego.

Wyróżnia się dwa rodzaje asocjacji:

• binarne

• n – arne _Class1 _Class2

Class3

Class1 Class2

(66)

Asocjacje – cechy

• nazwa

• rola

• nawigacja

Kierownik

projektu zarządza Projekt

Kierownik

projektu Projekt

szef

zarządza

zadanie

Kierownik

szef

zarządza

zadanie

(67)

Asocjacje – cechy

• liczebność - podając liczebność na pewnym końcu powiązania (przy pewnej klasie) wskazujemy ile obiektów tej klasy musi być połączonych z każdym obiektem klasy znajdującej się na przeciwnym końcu powiązania.

1 dokładnie jeden n dokładnie n (n>1)

1..* jeden lub wiele 1..n od 1 do n

0..1 zero lub jeden 0..n od 0 do n

* wiele n..m od n do m (n,m>1)

0..* zero lub wiele n,m..o liczebność złożona n..* więcej niż n

Kierownik

szef

1

zarządza zadanie

1..*

(68)

Asocjacje – agregacja całość-część

• Agregacja – opisuje związek całość-część pomiędzy klasami.

• Wyróżnia się dwa rodzaje agregacji:

 agregacja całkowita (kompozycja) – obiekty nie mogą samodzielnie funkcjonować, usunięcie agregatu

powoduje likwidację segmentów,

 agregacja częściowa – usunięcie agregatu nie powoduje usunięcia jego części, obiekty współdzielone mogą

funkcjonować samodzielnie

(69)

Związki – agregacja – przykład 1

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

(70)

Związki – agregacja – przykłady 2-3

Faktura Pozycja

1..*

1

Plansza OX Pole

9 1

(71)

Związki – agregacja – przykłady 4-5

Zamówienie Pozycja

1..*

1

Pracownik Ubezpieczenie

9

1 0..1

Powiązane elementy nie są sobie równorzędne

(72)

Związki – agregacja – przykład 1

Dodatkową funkcjonalnością powiązań jest agregacja częściowa (aggregation).

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

(73)

1 *

Związki – agregacja – przykład 2-3

Produkt Składowa

1 1 1 1..*

Zestaw komputerowy Klawiatura Klawisz

(74)

*

1 Pracuje w

Agregacja jest specjalną formą asocjacji, której podstawową intencją jest odwzorowanie związków część-całość

1. Czy właściwe jest użycie frazy “jest częścią”?

2. Czy operacje na całości automatycznie są propagowane na jej części?

3. Czy jakiś atrybut całości jest automatycznie propagowany do jej części?

4. Czy istnieje wewnętrzna asymetria w asocjacji, kiedy jakaś klasa jest podporządkowana innej klasie?

1 * 1 1..*

Firma Oddział Wydział

Osoba

(75)

Asocjacja zwrotna i wielokrotna

• asocjacja wielokrotna – połączenie klas kilkoma asocjacjami w zależności od pełnionych ról

• asocjacja zwrotna – powiązanie danej klasy z samą sobą

Programista Moduł

implementuje >

testuje >

Pracownik podwładny *

0..1 kierownik

(76)

Związek Kwalifikacja

Zapisując powiązanie możemy wskazać w jaki sposób mając dany obiekt na jednym końcu powiązania można zidentyfikować obiekt(-y) z drugiego końca.

Pracownik SpisPracowników IdPracownika

(77)

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.

(78)

Wniosek

Typ wniosku Nr księgi wieczystej Opłata sądowa

Ilość dokumentów Data złożenia Godzina złożenia Treść wniosku

Stwórz wniosek() Rejestruj wniosek() Wyszukaj wniosek() Przeglądaj wniosek()

Klasa Wniosek - przykład

(79)

Klasa abstrakcyjna Osoba

Osoba

Imię

Nazwisko

Data urodzenia Adres

Pracownik Stażysta Emeryt

/wiek Dodaj

Usuń (o:Osoba)

Modyfikuj (o:Osoba)

Wiek = Data bieżąca – Data urodzenia

(80)

Rodzaje diagramów klas – powtórka

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.

(81)

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.

(82)

Diagram klas – definicja – powtórka

• Diagram klas obrazuje pewien zbiór klas, interfejsów i kooperacji oraz związki między nimi. Jest to graf złożony z wierzchołków (klas, interfejsów, kooperacji) i łuków (reprezentowanych przez relacje)

• Diagram klas stanowi opis statyki systemu, który

uwypukla związki między klasami. Najsilniej prezentuje strukturę systemu, stanowiąc podstawę dla jego

konstrukcji.

• Diagram klas służy do zobrazowania statycznych

aspektów perspektywy projektowej, w której bierze się pod uwagę wymagania funkcjonalne systemu – usługi, jakie system powinien udostępniać swoim użytkownikom.

(83)

Etapy tworzenia diagramu klas – powtórka

1) zidentyfikowanie i nazwanie klas;

2) opcjonalnie określenie zobowiązań klas;

3) połączenie poszczególnych klas z wykorzystaniem związków asocjacji;

4) zidentyfikowanie oraz nazwanie atrybutów i operacji;

5) wyspecyfikowanie asocjacji z użyciem wszystkich jej cech (nazwy, ról, nawigacji, liczebności, agregacji, kwalifikacji);

6) opracowanie innych rodzajów związków, tj. uogólnień, zależności i realizacji;

7) pełne, precyzyjne wyspecyfikowanie atrybutów i operacji;

8) opcjonalnie opracowanie diagramów obiektów.

(84)

Przykłady

Diagramy klas

(85)

class Domain Obj ects

Menedżer - Imię:

- Nr_telefonu:

+ rozpocznij_projekt() : void + zakończ_projekt() : void

Zespół - Opis:

Proj ekt - Nazwa:

- Data_rozpoczęcia:

- Data_zakończenia:

kieruje

wykonuje

zarządza

Na diagramie przedstawione są następujące informacje:

- Menedżer przewodziMenedżer przewodzi zespołowizespołowi, który wykonujewykonuje projektprojekt

- Każdy menedżermenedżer ma imięimię i numer telefonunumer telefonu, i może zainicjować lub zakończyć (przerwać) projektprojekt

- Każdy projektprojekt ma nazwęnazwę, datę rozpoczęciadatę rozpoczęcia i datę zakończeniadatę zakończenia - Każdy zespółzespół ma opisopis, i tylko on nas interesuje

atrybuty

operacje

(86)

Atrybuty asocjacji – klasa asocjacyjna

Osoba

nazwisko pesel adres

Firma

nazwa adres

Zatrudnienie

zarobek stanowisko

zatrudnia

0..1 1..*

0..1 szef

Ocena wydajności

ocena

Dla asocjacji można zdefiniować opisujące ją atrybuty, tzw. atrybuty asocjacji.

W języku UML atrybuty asocjacji są umieszczone w specjalnej klasie zwanej klasą asocjacji, która jest połączona z asocjacją za pomocą przerywanej linii.

Przykładem klasy asocjacji jest klasa Zatrudnienie na rys, która przechowuje informacje o stanowisku zajmowanym przez osobę zatrudnioną w firmie oraz o pobieranym przez nią wynagrodzeniu.

(87)

Dziedziczenie asocjacji

• Asocjacje, podobnie jak np. atrybuty i metody, są dziedziczone przez podklasy.

• Na diagramie (rys.a) dwie asocjacje o nazwach asoc1 i asoc2 łączą klasę K z klasami K2 i K3, będącymi podklasami klasy K1.

• Aby, w oparciu o mechanizm dziedziczenia, te dwie asocjacje mogły być zastąpione przez jedną asocjację prowadzącą od K do K1 (rys.b), asocjacje z diagramu a muszą spełniać następujące warunki:

K1

K2 K

1. Muszą posiadać taką samą semantykę.

2. Muszą posiadać taką samą strukturę, tzn. muszą mieć takie same atrybuty lub taką samą klasę asocjacji

K3

asoc1 asoc2

K1

K2 K3 K

asoc

Rys.a Rys.b

(88)

Dziedziczenie asocjacji Referat

tytuł autorzy [1..*]

Sesja

nazwa data

Termin

godzina

wygłaszany 0..1 1..*

0..1 Referat zaproszony

Referat zwykły

ocena

Termin

godzina

wygłaszany

1

Asocjacja wygłaszany łączy klasę Sesja z podklasami

(89)

Sesja

nazwa data

Termin

godzina

wygłaszany 1..* 0..1

Referat zaproszony

Referat zwykły

ocena

Rys. Asocjacja wygłaszany łączy klasę Sesja z nadklasą

(90)

Sesja

nazwa data

Termin

godzina

wygłaszany 1..* 0..1

Referat zaproszony

Referat zwykły

ocena

Rys. Zdefiniowano brakujące ograniczenia

{-podczas sesji jest wygłaszany co najmniej jeden referat zwykły i co najmniej jeden zaproszony -referat zwykły może nie zostać wygłoszony - każdy referat zaproszony musi być wygłoszony}

(91)

Pracow nik

Nabyw ca

Produkt

Zamów ienie

Pozycj a na zamów ieniu 1

jest przypisane

0..*

1..*

współpracuje

0..*

interesuje się

1..*

1

składa

0..*

1

1..*

1

jest wyspecyfikowany

1..*

składa się

Konceptualny diagram klas – zamówienie produktów

(92)

Pracow nik

Nabyw ca - imie: char - nazwisko: char - adres: char

+ dodaj() : void + usun() : void

Produkt + create() : void

Zamów ienie

+ aktualizuj() : void

+ oblicz_wartosc(char) : void

Pozycj a na zamów ieniu + dodaj() : void 1

jest wyspecyfikowany

1..*

1

1..*

1

składa

0..*

interesuje się

1..*

współpracuje

0..*

1

jest przypisane

0..*

Diagram klas – zamówienie produktów

(93)

Przykład – sprzedaż wysyłkowa

• Wszystkie transakcje realizowane w przedsiębiorstwie sprzedaży wysyłkowej zaczynają się od złożenia przez klienta zamówienia na potrzebne mu towary.

• W systemie istnieje więc klasa Klient, zawierająca

wszystkich nabywców, oraz klasa Zamówienie, z których każde określa kupowane towary.

• Każdy obiekt należący do klasy Klient ma takie same

atrybuty, np. nazwisko i adres, i każdy może wykonywać te same operacje, np. złożyć zamówienie.

• Podobnie, każdy obiekt należący do klasy Zamówienie ma takie same atrybuty, np. data złożenia, adres dostawy oraz status, i każdy może wykonać te same operacje, np.

wydrukować swą treść oraz obliczyć wymaganą zaliczkę, przedpłatę, całkowitą wartość i podatek.

(94)

Pozycj a - ilość: int - cena: double + obliczWartość() : void + drukuj() : void + obliczZaliczkę() : void

Zamów ienie - data: data

- adresOdbiorcy: char - status: char + drukuj() : void + obliczWartość() : void + drukujFakturę() : void + wyślij() : void + zamknij() : void

Klient - nazwa: char - adres: char + zamów() : void

Tow ar - nazwa: char - cena: int - producent: char - stopaVAT: double + drukujOpis() : void + czyZaliczka() : void

Płatność - data: data - kwota: int + zaksięguj() : void

Przelew - idPrzelewu: int - nrKonta: int

WpłataGotów kow a - nazwaKuriera: char

Opona - rozmiar: int

Fotelik - wagaDziecka: int - opis: char

Pokrow iec - kolor: char 0..*

wskazuje 1

1..* 1

składa 0..*

* dotyczy

1..*

Diagram klas systemu sprzedaży wysyłkowej

Modelem obrazującym strukturę i wzajemne powiązania obiektów występujących w systemie jest diagram klas.

(95)

Diagramy klas - Ćwiczenie

Zbuduj diagram klas w oparciu o diagram przypadków użycia.

uc Biblioteka

Personel biblioteczny

w ypożycz książkę

spraw dź czy można w ypożyczyć danemu

czytelnikow i

spraw dź dostępność książki

rej estracj a w ypożyczenia

«include»

«extend»

(96)

Unified Modeling Language

Diagramy struktury:

• diagram klas (class diagram)

• diagram obiektów (object diagram)

• diagram komponentów (component diagram)

• diagram pakietów (package diagram)

• diagram wdrożenia (deployment diagram)

• zbiorowy diagram

komponentów (composite structure diagram)

Diagramy dynamiki:

• diagram przypadków użycia (use case diagram)

• diagram czynności (activity diagram)

• diagram maszyny stanów (state machine diagram)

• diagram sekwencji (sequence diagram)

• diagram komunikacji

(communication diagram)

• diagram przeglądu

współdziałania (interaction overview diagram)

• diagram czasowy (timing diagram)