background image

 

 

Diagramy klas

Halina Tańska

background image

 

 

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

 

background image

 

 

Diagram klas

Kluczowymi elementami są

:

• klasy (class)
• związki (association)
• interfejsy (interface)

Dodatkowo diagram może zwierać

:

• notatki (note)
• ograniczenia (constraints)
• pakiety (packages)

background image

 

 

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.

background image

 

 

Diagram klas

Klasa jest 

opisem zbioru obiektów

które mają takie same:

•atrybuty
•operacje
•związki
•znaczenia

background image

 

 

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.

background image

 

 

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.

background image

 

 

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.

background image

 

 

dokonanie 
rejestracji

zarejestrowanie 

Właściciel

własność

wniesienie 

rejestrację

Rejestrator 

wykonanie 
czynności 
urzędowej

Rejestracja 

Pojazd

background image

 

 

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. 

background image

 

 

Diagram klas

Klasa w notacji 
UML

Nazwa

Atrybuty

Operacje

background image

 

 

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.

background image

 

 

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.

background image

 

 

W  związku  z  różnorodnością  możliwych 

sposobów  specyfikowania  klas  należy 

wyróżnić 

następujące 

opcje 

ich 

prezentacji graficznej:

sama  nazwa  klasy  umieszczona  w 

jednosekcyjnym bloku oznacza, że sekcje 

atrybutów 

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; 

background image

 

 

Student

Oblicz średnia(): 
real

Nr indeksu: 
integer 
Nazwisko: 
string Oceny: 
string

Student

Oblicz 
średnia()

Nr 
indeksu 
Nazwisko 
Oceny

Student

Nr 
indeksu 
Nazwisko 
Oceny

Różne poziomy szczegółowości

Student

background image

 

 

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

background image

 

 

Nazwa klasy

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

background image

 

 

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

background image

 

 

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

background image

 

 

Klasa

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

Operacj
e

background image

 

 

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

background image

 

 

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

background image

 

 

Klasa

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.

background image

 

 

Polimorfizm

• Metody danego obiektu są realizowane po 

otrzymaniu komunikatu od innego obiektu, 

żądającego realizacji metody. Komunikat taki składa 

się z identyfikatora obiektu – odbiorcy komunikatu, 

metody, którą obiekt odbiorca powinien wykonać, 

oraz opcjonalnie parametrów, wskazujących 

obiektowi – odbiorcy, jak wykonać wskazaną metodę.

• Jeżeli ten sam komunikat – zawierający tę samą 

nazwę operacji – wysłany do różnych obiektów 

powoduje wykonanie różniących się między sobą 

metod, to mamy do czynienia z polimorfizmem – tj. 

ta sama nazwa odnosi się do różnych implementacji 

operacji. 

background image

 

 

Enkapsulacja 

(hermetyzacja)

• Enkapsulacja (hermetyzacja) 

oznacza traktowanie obiektu jako 
kapsuły, pełniącej określoną rolę w 
systemie. Kapsuła stanowi „czarną 
skrzynkę”, udostępniającą tylko 
niezbędne informacje i ukrywającą 
pozostałe. 

background image

 

 

Hierarchie klas

• Klasy obiektów mogą tworzyć hierarchię. 

Klasa podrzędna (podklasa) dziedziczy 

atrybuty i metody klasy nadrzędnej. Nie 

trzeba ich ponownie definiować dla podklasy. 

Hierarchie klas są tworzone poprzez 

operacje generalizacji i specjalizacji. 

Generalizacja oznacza budowanie pojęć 

bardziej ogólnych na podstawie pojęć 

bardziej szczegółowych. Specjalizacja jest 

budowaniem pojęć bardziej szczegółowych 

wywodzących się z pojąć bardziej ogólnych.

background image

 

 

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.

background image

 

 

Klasa

Odpowiedzialność klasy

background image

 

 

class Logical View

Kurs

Wykład

Student

Pracownik

Osoba

Profesor

+poprzedni
0..1

+następny
*

1..*

+zapisany na

1..*

*

+prowadzący

1

background image

 

 

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

background image

 

 

Klasa

Widoczność Public

+

Każdy ma dostęp do elementów klasy 
(atrybutów i operacji) oznaczonych 
jako public.

background image

 

 

Klasa

Widoczność Protected

#

Atrybut lub operacja jest widoczna dla 
potomków klasy.

background image

 

 

Klasa

Widoczność Private

-

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

background image

 

 

Klasa

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

background image

 

 

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

background image

 

 

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.

background image

 

 

Interfejs

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

background image

 

 

Interfejsy

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

background image

 

 

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.

background image

 

 

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:

background image

 

 

Interfejs dostarczany

Nazwa interfejsu:
• prosta

np.: IPisownia

• ścieżkowa 

np.: UsługiSieciowe::IRouter

background image

 

 

Interfejs dostarczany

Interfejs jest 

definicją usług 

oferowanych

 przez klasę lub 

komponent.

background image

 

 

Interfejs wymagany

Interfejs wymagany są to 

usługi, 

które inne klasy muszą dostarczyć 
w celu zapewnienia odpowiedniego 
funkcjonowania klasy w 
środowisku

.

background image

 

 

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.

background image

 

 

Interfejs

Interfejs wymagany i dostarczany

OCENY

protokółEgzamina
cyjny

IOceny

background image

 

 

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

background image

 

 

Asocjacja

Asocjacja opisuje związek strukturalny miedzy 
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

background image

 

 

Asocjacje – cechy

• nazwa

• rola

• nawigacja

Kierownik 

projektu

Projekt

zarządza

Kierownik 

projektu

Projekt

szef

zarządza

zadanie

Kierownik 

projektu

Projekt

szef

zarządza

zadanie

background image

 

 

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 

projektu

Projekt

szef

1

zarządza

zadanie

1..*

background image

 

 

Związki

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

background image

 

 

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

background image

 

 

Laboratoriu
m

StanowiskoKompute
rowe

<<use
>>

Typowe zastosowanie zależności typu <<use>> 
- do prawidłowego działania klasy Laboratorium 
jest potrzebne użycie klasy 
StanowiskoKomputerowe

background image

 

 

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

background image

 

 

Związki

Uogólnienie

Dziekan 

Wykładow
ca

background image

 

 

class Domain Objects

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

Uogólnienie - generalizacja

background image

 

 

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.

background image

 

 

Związki

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

background image

 

 

Asocjacje – cechy

• agregacja – opisuje związek całość-część 

pomiędzy klasami. Wyróżnia się dwa 
rodzaje agregacji:

 agregacja całkowita – 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

background image

 

 

Związki

Dodatkową funkcjonalnością powiązań 
jest agregacja (aggregationi 
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.

background image

 

 

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

background image

 

 

Firma

Osoba

Pracuje w

Oddział

Wydział

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 

propagowny do jej części?

4. Czy istnieje wewnętrzna asymetria w asocjacji, 

kiedy jakaś klasa jest podporządkowana innej 
klasie?

background image

 

 

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

background image

 

 

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

background image

 

 

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.

background image

 

 

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”

background image

 

 

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. 

background image

 

 

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

.

background image

 

 

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

background image

 

 

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.  

background image

 

 

class Domain Objects

Menedżer

Imię:  

Nr_telefonu:  

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

Zespół

-  Opis:  

Projekt

-  Nazwa:  
-  Data_rozpoczęcia:  
-  Data_zakończenia:  

kieruje

wykonuje

zarządza

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

-Menedżer przewodzi zespołowi, który wykonuje projekt
-Każdy menedżer ma imię i numer telefonu, i może zainicjować 
lub zakończyć (przerwać) projekt

- Każdy projekt ma nazwę, datę rozpoczęcia i datę zakończenia
-Każdy zespół ma opis, i tylko on nas interesuje

atrybuty

operacj
e

background image

 

 

Atrybuty asocjacji

Osoba

nazwisk
o pesel  
adres

Firma

nazwa   
adres

Zatrudnien
ie

zarobek 
stanowisko

zatrudnia

0..1

1..*

0..
1

sze
f

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.

background image

 

 

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

K

K3

asoc

Rys.a

Rys.b

background image

 

 

Dziedziczenie asocjacji

Refera
t

tytuł         
autorzy [1..*]

Sesja

nazwa   
data

Termin

godzin
a

wygłaszany 0..1

1..*

0..
1

Referat 
zaproszony

Referat 
zwykły

ocena

Termin

godzin
a

wygłaszany

1

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

background image

 

 

Dziedziczenie asocjacji

Refera
t

tytuł         
autorzy [1..*]

Sesja

nazwa   
data

Termi
n

godzin
a

wygłaszany

0..1

1..*

Referat 
zaproszony

Referat 
zwykły

ocena

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

background image

 

 

Dziedziczenie asocjacji

Refera
t

tytuł         
autorzy [1..*]

Sesja

nazwa   
data

Termi
n

godzin
a

wygłaszany

0..1

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}

background image

 

 

class Logical View

Pracownik

Nabywca

Produkt

Zamówienie

Pozycja na 

zamówieniu

1

jest przypisane

0..*

1..*

współpracuje

0..*

0..*

interesuje się

1..*

1

składa

0..*

1

1..*

1

jest wyspecyfikowany

1..*

background image

 

 

Diagramy klas

background image

 

 

Diagramy klas

background image

 

 

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.


Document Outline