dr inż. Włodzimierz Dąbrowski
Politechnika Warszawska, Wydział Elektryczny

[e-mail]

Podstawy inżynierii oprogramowania

Związki między klasami

14

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Czym jest związek klas

• Semantyczny związek między dwoma lub

więcej klasami określający zależności
między ich instancjami.

• Związek strukturalny mówiący o tym, że

obiekty jedenj klasy są połączone z

obiektami innej klasy.

Kurs

Student

Plan

16

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Cechy związków

Student

Wykład

0..*

0..*

zapisany na

0..*

wybrany przez

0..*

Rejestracja

Związek oznaczany jest linią uzupełnioną o:

•

nazwę związku,

•

role klas,

•

nawigowalność,

•

krotność,

•

uporządkowanie.

17

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Kierunek związków

• Kierunek (nawigowalność) związku oznacza, że z obiektów jednej z

klas można bezpośrednio osiągnąć obiekty drugiej.

– Klasa po stronie bez grotu jest klientem, a klasa po stronie z grotem jest

serwerem w związku. Klient może korzystać z usług serwera.

– Klient posiada wiedzę o serwerze, zatem musi posiadać do niego jakieś

łącze (wskazanie lub deklaracja zmiennej klasy serwera).

– Związki mogą być nawigowalne w obydwie strony - wtedy nie rysuje się

grotów. Uwaga: związek bez grotów może oznaczać brak nawigowalności.

Właściciel

Pojazd

Zamówienie

Klient

1

0..*

0..*

1

18

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Liczność

• Liczność związku określa liczbę instancji klasy

pozostającej w zależności do JEDNEJ instancji
innej klasy

• Dla każdego związki określa się minimalną i

maksymalną liczbę obiektów lub konkretną wartość

– Z każdą instancją klasy Professor może być

skojarzonych wiele instancji klasy CourseOffering

– Z każdą instancją klasy CourseOffering może być

skojarzony co najwyżej jedna instancja klasy Professor.

Professor

CourseOffering

0..1

0..*

0..1

0..*

instructor

19

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Oznaczenia liczności

2..4

0..1

1..*

0..*

1

*

2, 4..6

Nieznane

Dokładnie jeden

Zero lub więcej

Zero lub więcej

Zero lub jeden

(

wartość opcjonalna

)

Jeden lub więcej

Zakres

Kilka zakresów rozłącznych

21

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Przykład: Liczności związku

Zamówienie

Klient

1

0..*

0..*

1

Zamówienie

Faktura

0..1

1..*

0..1

1..*

Poseł

Klub poselski

0..1

15..460

0..1

15..460

23

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Agregacja

• Szczególny typ asocjacji modelujący związek

całość-część.

– Agregacja jest związkiem typu „jest częścią

czegoś”

Część

Całość

0..1

1

24

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Przykład: Agregacja

RegisterForCoursesForm

CourseOffering

Schedule

0..4

0..*

Student

0..*

1

RegistrationController

1

1

1

1

0..1

0..1

0..1

25

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Aagregacja jest asocjacją: dla obu jej końców są określane

liczności, a także może mieć atrybuty.

Grupa

Student

Termin

od
do

*

1..15

Agregacja jako klasa

26

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Własności agregacji

A

B

 jest relacją niesymetryczną,
tzn. jeśli B jest częścią

A, to A nie jest częścią B

A

B

C

 jest relacją przechodnią
(tranzytywną), tzn. jeśli C jest

częścią B i B jest częścią A, to C

jest częścią A

27

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Kiedy stosować agregację?

 Kryterium istnienia,
 Kryterium wstawiania,
 Kryterium usuwania,
 Kryterium fizycznej części.

Grupa

Termin

od
do

*

1..15

zmień plan

Student

zmień plan

zmień plan

plan

plan

28

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Kompozycja

• Szczególny typ agregacji narzucający silną

kontrolę własności i czasu życia części przez
całość

• Składniki kompozycji nie istnieją samoistnie i

giną wraz z kompozytem.

Nagłówek

Suwak

Okno

1

1

1

1

1

1

0..2

29

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Agregacja rekursywna 1/3

K

?

?

Obiekt klasy K może zarówno wchodzić w
skład innych obiektów klasy K, jak i
zawierać obiekty klasy K.

K

0..1

0..1

:K

:K

:K

30

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Agregacja rekursywna 2/3

K

0..1

*

:K

:K

:K

:K

:K

:K

:K

 Czy można tu zastosować liczność dokładnie 1 zamiast 0..1 i liczność 1..* zamiast

liczności * ?

Część

nazwa
materiał
rozmiary

0..1

*

I

II

Firma

Oddział

1

*

*

0..1

 Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji

wydaje się być bezdyskusyjna?

31

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Agregacja rekursywna 3/3

K

*

*

:K

:K

:K

:K

:K

:K

:K

Program

1..*

Blok

Instrukcja

złożona

Instrukcja

prosta

0..1

1

*

I

II

Człon

*

Wyrażenie

operator binarny

Zmienna

nazwa

1

Stała

wartość

*

1

2-gi operand

1-szy operand

 Jak wyglądałby

diagram obiektowy
dla wyrażenia, np.

(x + y/2) * (x/3 - y)

32

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Kwalifikator jest atrybutem asocjacji (lub zestawem atrybutów), którego wartości
służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na
drugim końcu asocjacji.

Bank

Osoba

nr konta

Bank

1..*

0..1

0..1

Bank

Osoba

nr konta

Bank

Osoba

*

*

*

Bank/Osoba

nr konta

kwalifikator
asocjacji

Osoba

nr konta

1

0..1

Asocjacja kwalifikowana

33

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

nazwa produktu

Zamówienie

WierszZamówienia

ilość

0..1

pozycja

Zamówienie

WierszZamówienia

nazwa produktu
ilość

*

pozycja

1

1

Asocjacja kwalifikowana

34

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Asocjacja

n-arna

to asocjacja, której wystąpienia

łączą

n

obiektów, będących instancjami co najwyżej n klas: 3-arna - 3
obiekty (inna nazwa dla tej asocjacji to ternarna), 4-arna - 4 obiekty,
itd. Dana klasa może pojawić się na więcej niż jednej pozycji w
asocjacji.

K1

K2

K3

nazwa

asocjacji

K1

K2

K3

asocjacja

3-arna

asocjacja

4-arna

Asocjacja n-arna

36

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Role asocjacji

Asocjacje mogą być wyposażone w nazwy ról (przy
końcach asocjacji), np. pracodawca i pracownik.

Firma

Osoba

pracuje_dla

*

1..*

pracodawca

pracownik

szef

podwładny

*

0..1

Można opuszczać nazwę asocjacji, gdy jest
oczywista (?)

i jest

jedyną asocjacją łączącą

dwie klasy.

Firma

Pracownik

1..*

1

37

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

jest_członkiem

*

*

jest_przewodniczącym

1

*

Na diagramie

powyżej, dwie asocjacje łączą te same klasy; w takim

wypadku

(dwie klasy

połączone więcej niż jedną

asocjacją)

wszystkie asocjacje

muszą być oznaczone.

(2) Do oznaczenia asocjacji można użyć nazwy, dwóch ról lub

jednej roli.

Pracownik

szef

*

0..1

Osoba

Komitet

Role asocjacji

38

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Plik

Użytkownik

Prawo dostępu
dostęp

dostępny

dla

{

dostęp oznacza:

czytanie lub

czytanie-pisanie}

*

*

Przykład 1

Przykład 2

Przykład: Atrybuty asocjacji

Osoba

nazwisko
pesel
adres

Firma

nazwa
adres

Zatrudnienie
zarobek
stanowisko

szef

pracuje_w

Ocena wydajności
ocena

0..1

*

0..1

1..*

39

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Kiedy wykorzystywać atrybuty asocjacji?

Forma nie zalecana, mniej elastyczna:
np. po zmianie powiązania na wiele-do-
wielu

trzeba

zmieniać

położenie

atrybutów.

Zalecane jest, by

przypisywać do klasy

tylko te atrybuty,

które są dla tej klasy

stabilne.

Eksperyment myślowy: co będzie, jeżeli
liczność asocjacji się zmieni? Dość często
okazuje się wtedy, że atrybut jest atrybutem
asocjacji, a nie klasy.

Osoba

nazwisko
pesel
adres

Firma

nazwa
adres

pracuje_w

Zatrudnienie
zarobek
stanowisko

0..1

1..*

Osoba

nazwisko
pesel
adres
zarobek
stanowisko

Firma

nazwa
adres

pracuje_w

0..1

1..*

40

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Atrybuty i asocjacje pochodne

Własność pochodna jest zdefiniowana poprzez funkcję działającą na jednym lub więcej
bytach modelu, które też mogą być pochodne. Własność pochodna oznaczana jest przez
poprzedzenie jej nazwy ukośnikiem /.

data_urodzenia
/wiek

{wiek = data_bieżąca - data_urodzenia}

Asocjacja pracuje_w jest asocjacją pochodną,

którą można wyznaczyć poprzez

asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną oznacza się poprzedzając
ukośnikiem nazwę lub rolę asocjacji.

atrybut pochodny: /wiek

Wydział

Sekcja

Pracownik

Budynek

zatrudnia

zlokalizowana_w

/pracuje_w

*

*

*

*

Osoba

asocjacja pochodna: /pracuje_w

1

1

1

1

41

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

42

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Generalizacja

• Związek między klasami o wspólnej

strukturze i/lub zachowaniu

• Definiuje hierarchie abstrakcji, w której

podklasa dziedziczy z nadklasy

43

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Przykład: Proste dziedziczenie

Checking

Savings

Superclass

(parent)

Subclasses

(children)

Generalization

Relationship

Descendents

Ancestor

Account

- balance
- name
- number

+ withdraw()
+ createStatement()

44

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Przykład: Wielodziedziczenie

• Klasa może dziedziczyć z kilku nadklas

FlyingThing

Animal

Horse

Wolf

Bird

Helicopter

Airplane

Multiple Inheritance

45

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie

Dziedziczenie

pozwala na tworzenie drzewa

klas lub innych struktur bez pętli.

specjaliz

acja

gen

erali

z

acja

Pracownik

Osoba

Asystent

Adiunkt

Profeso

r

Docent

Asystent

Adiunkt

Profeso

r

Docent

Pracownik

Osoba

46

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie

K1

K2

K3

Struktura typu pętla
jest zabroniona

Pracownik

Student

Osoba

Student_asystent

Struktura typu krata
jest dopuszczalna

47

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie

NAZWISKO
ROK_UR
Wiek()

ZAROBEK
DZIAŁ
FOTO
ZarobekNetto()
ZmieńZarobek(...)

NR_INDEKSU
WYDZIAŁ
WstawOcenę(...)
ZaliczSemestr()

JPEG

GIF

GRAFIKA
ROZMIAR
Wyświetl(...)

Atrybut PRACOWNIKa
FOTO jest obiektem należącym
do klasy JPEG.

OSOBA

STUDENT

PRACOWNIK

«instance of»

48

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie

powierzchnia wymiany
średnica rury

Zbiornik

objętość
ciśnienie

typ wyposażenia

typ pompy

typ zbiornika

aspekt specjalizacji
(dyskryminator)

Wyposażenie

nazwa
wytwórca
koszt

Dyskryminator jest atrybutem opcjonalnym

Wymiennik ciepła

ciśnienie ssania
ciśnienie tłoczenia
przepływ

Pompa

49

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie

Wyposażenie

nazwa
wytwórca
koszt
ciśnienie ssania
ciśnienie tłoczenia
przepływ
powierzchnia wymiany
średnica rury
objętość
ciśnienie
typ wyposażenia

ciśnienie ssania
ciśnienie tłoczenia
przepływ

powierzchnia wymiany
średnica rury

Zbiornik

objętość
ciśnienie

typ wyposażenia

Wyposażenie

nazwa
wytwórca
koszt

Pompa

Wymiennik ciepła

50

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie wieloaspektowe

Pojazd

{overlapping}

Pojazd

wiatrowy

Pojazd

silnikowy

Pojazd

lądowy

Pojazd

wodny

napęd

teren

teren

{overlapping}

Drzewo

Dąb

Brzoza

Sosna

gatunek drzewa

{incomplete}

2 aspekty: napęd i teren

51

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie wielokrotne

Dziedziczenie wielokrotne ma miejsce, gdy klasa dziedziczy inwarianty z więcej niż
jednej klasy.

Nazwisko

Osoba

Pracownik

Zarobek

Student

Nr_indeksu

Pracujący_

student

52

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Problemy dziedziczenia wielokrotnego

Kontrola typu: Jaki będzie wynikowy typ obiektów Amfibia?

Najczęściej wielodziedziczenie jest konsekwencją braku koncepcji ról.

Konflikt nazw: Który atrybut max_prędkość ma odziedziczyć amfibia?

Czy znaczenie metody prędk_eksploat() zależy od ścieżki dziedziczenia?

(O2: mechanizm zmiany nazwy dziedziczonej cechy; Eiffel: konflikt jest traktowany jako błąd.)

Pojazd

{prędkość eksploatacyjna wynosi
50% prędkości maksymalnej}

max_prędkość

max_prędkość
prędk_eksploat()

Amfibia

Samochód

Jacht

prędk_eksploat()

Pojazd lądowy

Pojazd wodny

53

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Dziedziczenie dynamiczne

Osoba

Manager

Inżynier

Sprzedawca

Kobieta

Mężczyzna

{mandatory}

płeć

«

dynamic

»

Osoba

może zmieniać zawód, co można modelować poprzez tzw. dziedziczenie

dynamiczne. Przydatne dla modelowania koncepcyjnego, ale

może być trudne

w implementacji.

mandatory -

obowiązujący, obowiązkowy

W

ogólności, dyskryminator dynamiczny może być związany z dziedziczeniem

nierozłącznym (overlapping).

zawód

Dyskryminator

zawód został tu opatrzony stereotypem

«

dynamic

»

.

59

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Klasa abstrakcyjna a konkretna (1)

Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłącznie
jako nadklasa dla innych klas. Stanowi jakby wspólną część definicji grupy klas o
podobnej

semantyce. UML pozwala na oznaczenie bytu

abstrakcyjnego za pomocą

wartości etykietowanej {abstract = TRUE} (TRUE można opuścić) lub napisanie
nazwy bytu abstrakcyjnego italikami (np. nazwy klasy czy metody abstrakcyjnej).

Klasa konkretna może mieć (ma prawo mieć) wystąpienia bezpośrednie.

Osoba prawna

{abstract}

Osoba fizyczna

Firma

Sekwencja

pierwszy
następny

Sekwencja int

...

implementacje

Sekwencja char

.

..implementacje

Klasyczna klasyfikacja w
biologii: tylko liście
w drzewie klas mogą być
klasami konkretnymi.

60

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,

Klasa abstrakcyjna a konkretna (2)

A - klasa abstrakcyjna

K - klasa konkretna

K1

K2

K3

K4

K5

K

A,K

A,K

K

K

Klasa abstrakcyjna nie może znaleźć się w liściu drzewa.

Klasa konkretna może zająć każde położenie.

61

2008-04-04

W.Dąbrowski Podstawy inżynierii oprogramowania,