1

Podstawy programowania II

dr inż. Paweł Róg  

2

Zagadnienia

■

Co to jest paradygmat programowania?



Programowanie imperatywne



Programowanie funkcyjne



Programowanie logiczne



Programowanie obiektowe

■

Cechy programowania obiektowego



Abstrakcja



Dziedziczenie



Dynamiczne wiązania i polimorfizm

■

Język UML



Geneza



Perspektywy



Diagramy

3

Co to jest paradygmat programowania?

■

„przyjęty sposób widzenia rzeczywistości w danej 

dziedzinie, doktrynie itp.” lub „zespół form fleksyjnych 

(deklinacyjnych lub koniugacyjnych), właściwy 

danemu typowi wyrazów; wzorzec, model deklinacyjny 

lub koniugacyjny” (Słownik języka polskiego PWN)

■

παράδειγμα (gr.) - wzorzec, przykład

■

zbiór mechanizmów, jakich programista używa, pisząc 

program, i  to, jak ów program jest następnie 

wykonywany przez komputer

■

Paradygmat programowania to ogół oczekiwań 

programisty wobec języka programowania 

i komputera, na którym będzie działał program

4

Wybrane paradygmaty programowania

■

Programowanie imperatywne

■

Programowanie funkcyjne

■

Programowanie w logice (programowanie 
logiczne)

■

Programowanie obiektowe

5

Programowanie imperatywne

■

Programowanie imperatywne to najbardziej pierwotny sposób 

programowania, w którym program postrzegany jest jako ciąg 

poleceń dla komputera



Obliczenia rozumiemy tu jako sekwencję poleceń zmieniających 

krok po kroku stan maszyny, aż do uzyskania oczekiwanego 

wyniku. 



Stan maszyny należy z kolei rozumieć jako zawartość całej 

pamięci oraz rejestrów i znaczników procesora. 



Ten sposób patrzenia na programy związany jest ściśle z budową 

sprzętu komputerowego o architekturze von Neumanna, w którym 

poszczególne instrukcje (w kodzie maszynowym) to właśnie 

polecenia zmieniające ów globalny stan. 



Języki wysokiego poziomu — takie jak Fortran, Algol, Pascal, Ada 

lub C — posługują się pewnymi abstrakcjami, ale wciąż 

odpowiadają paradygmatowi programowania imperatywnego. 



Przykładowo, instrukcje podstawienia działają na danych 

pobranych z pamięci i umieszczają wynik w tejże pamięci, zaś 

abstrakcją komórek pamięci są zmienne.

6

Program w języku imperatywnym

program pierwszy;
       var i, n, s: integer;
    begin

       read(n);
       s := 1;

       for i := 2 to n do
          s := s * i;

       write(s)
    end.

7

Programowanie funkcyjne

■

W programowaniu funkcyjnym program to po prostu złożona 

funkcja (w sensie matematycznym), która otrzymawszy dane 

wejściowe wylicza pewien wynik



Zasadniczą różnicą w stosunku do innych paradygmatów 

jest brak stanu maszyny: nie ma zmiennych, a co za tym 

idzie nie ma żadnych efektów ubocznych. 



Nie ma też imperatywnych z natury, tradycyjnie rozumianych 

pętli (te wymagają np. zmiennych do sterowania ich 

przebiegiem). 



Konstruowanie programów to składanie funkcji, zazwyczaj 

z istotnym wykorzystaniem rekurencji. Charakterystyczne 

jest również definiowanie funkcji wyższego rzędu, czyli 

takich, dla których argumentami i których wynikami mogą 

być funkcje (a nie tylko „proste” dane jak liczby lub napisy).

8

Program w języku funkcyjnym

(DEFINE (suma m n)
  (IF (> m n)
    0

    (+ m (suma (+ m 1) n))
  )

)

9

Programowanie w logice

■

Na program składa się zbiór zależności 
(przesłanki) i pewne stwierdzenie (cel)



Wykonanie programu to próba udowodnienia celu 

w oparciu o podane przesłanki. 



Obliczenia wykonywane są niejako „przy okazji” 

dowodzenia celu. 



Podobnie jak w programowaniu funkcyjnym, nie 

„wydajemy rozkazów”, a jedynie opisujemy, co 

wiemy i co chcemy uzyskać.

10

Program w języku logicznym

ojciec(jan, jerzy).
ojciec(jerzy, janusz).
ojciec(jerzy, józef).
dziadek(X, Z) :- ojciec(X, Y), ojciec(Y, Z).
?- dziadek(X, janusz).

11

Programowanie obiektowe

■

W programowaniu obiektowym program to zbiór 

porozumiewających się ze sobą obiektów, czyli jednostek 

zawierających pewne dane i umiejących wykonywać na nich pewne 

operacje



Ważną cechą jest tu powiązanie danych (czyli stanu) 

z operacjami na nich (czyli poleceniami) w całość, stanowiącą 

odrębną jednostkę — obiekt. 



Cechą nie mniej ważną jest mechanizm dziedziczenia, czyli 

możliwość definiowania nowych, bardziej złożonych obiektów, na 

bazie obiektów już istniejących.

■

Zwolennicy programowania obiektowego uważają, że ten paradygmat 

dobrze odzwierciedla sposób, w jaki ludzie myślą o świecie 



Nawet jeśli pogląd ten uznamy za przejaw pewnej egzaltacji, to 

niewątpliwie programowanie obiektowe zdobyło ogromną 

popularność i wypada je uznać za paradygmat obecnie 

dominujący.

12

Program w języku obiektowym

public class Hello {

public static void main(String[] args)

System.out.println("Hello, I am James B.");

}

}

13

Konkretny język programowania

 

ucieleśnia jeden lub więcej 

paradygmatów

■

Fortran, Pascal i C to języki pozwalające 
stosować paradygmat programowania 
imperatywnego. Mówi się wręcz, że są to języki 
imperatywne. 

■

Java bądź C# to z kolei języki obiektowe, 
w których typowe programowanie imperatywne 
zostało mocno ograniczone. 

■

Natomiast C++ jest językiem zarówno 
obiektowym, jak i imperatywnym.

14

Programowanie obiektowe

■

Idea programowania zorientowanego obiektowo 
swoimi korzeniami sięga języka Simula 67, 
zaprojektowanego przez Ole-Johana Dahla 
i Kristena Nygaarda jako język do zastosowań 
symulacyjnych. W pełni rozwinięta została 
w Smalltalku 80, zaprojektowanym jako język 
„czysto obiektowy”, o jednolitej, klarownej 
składni. Prawdziwa powszechność i sukces 
komercyjny przyszły natomiast wraz z językiem 
C++, a później Java.

15

Programowanie obiektowe

■

Język obiektowy musi posiadać trzy 
podstawowe cechy: 



Abstrakcyjne typy danych. 



Dziedziczenie. 



Dynamiczne wiązania wywołań metod z metodami 

(ściślej: z definicjami metod).

16

Klasy, obiekty i podklasy

■

Abstrakcyjne typy danych w językach obiektowych zwykle 

nazywane są klasami. 

■

Instancje klas są nazywane obiektami. 

■

Klasa, która zdefiniowana została poprzez dziedziczenie z innej 

klasy, nazywana jest klasą pochodną bądź podklasą. 

■

Klasa, z której wywiedziono podklasę, nazywana jest klasą 

bazową lub nadklasą. 

■

Podprogramy, które definiują operacje na obiektach klasy, to 

metody. 

■

Odwołania do metod czasem nazywa się komunikatami. 

■

Zbiór wszystkich metod danego obiektu nazywany jest 

protokołem komunikatów tegoż obiektu.

17

O obiektach słów parę

1.Wszystko jest obiektem

2.Program jest zbiorem obiektów, które poprzez 

wysyłanie komunikatów mówią sobie nawzajem, co 

robić

3.Każdy obiekt posiada własną pamięć, na która 

składają się inne obiekty

4.Każdy obiekt posiada swój typ

5.Wszystkie obiekty danego typu mogą otrzymywać 

te same komunikaty

Obiekt ma stan, zachowanie i tożsamość

Obiekt ma stan, zachowanie i tożsamość

18

Obiekt posiada interfejs

Żarówka

zapal()
zgaś()

rozjaśnij()

przyciemnij()

Nazwa typu

Interfejs

Zarowka zr = new Zarowka();
zr.zapal();

19

Obiekt dostarcza usługi

■

Program świadczy pewne usługi dla użytkownika, 

realizując je przy pomocy usług oferowanych przez 

inne obiekty

■

Naszym celem jest stworzenie grupy obiektów (lub 

odszukanie istniejącej biblioteki zawierającej takie 

obiekty!) udostępniających usługi, które optymalnie 

nadają się do rozwiązania problemu

■

Obiekty powinny się cechować wysoką spójnością 

– dostarczać wyspecjalizowane usługi – realizować 

dobrze jedno zadanie, nie robić zbyt wiele 

20

Dziedziczenie

Figura

narysuj()
wymaż()
przesuń()
zwróćKolor()
ustawKolor()

Okrąg

Trójkąt

Kwadrat

odwróćPoziomo()
odwróćPionowo()

21

Przesłonięcie

Figura

narysuj()
wymaż()
przesuń()
zwróćKolor()
ustawKolor()

Okrąg

Trójkąt

Kwadrat

narysuj()
wymaż()

narysuj()
wymaż()

narysuj()
wymaż()

22

Ukrywanie implementacji

■

Twórcy klas (ang. class creators) 
i programiści-klienci (ang. client 
programmers)

■

Programista-klient nie powinien dotykać 
delikatnego wnętrza obiektu

■

Projektant biblioteki powinien móc wymienić 
wewnętrzne mechanizmy klasy, nie psując 
programu programisty-klienta

■

Poziomy dostępu: public, private i protected

23

Sterowanie dostępem

■

W najprostszym przypadku klasa dziedziczy wszystkie byty 

swojej nadklasy. 

■

Sterowanie dostępem pozwala programiście na ukrycie części 

typu abstrakcyjnego przed klientem poprzez zadeklarowanie 

pewnych bytów jako publiczne (public), a innych jako prywatne 

(private). 

■

Trzeciej kategorii sterowania dostępem, chroniony (protected), 

używa się, aby umożliwić dostęp do bytów klasom pochodnym, 

a jednocześnie zabronić dostępu do nich klientom. 

■

Klasa pochodna może modyfikować dziedziczone metody. 

Zmodyfikowana metoda ma tę samą nazwę; często także ten 

sam protokół. Mówi się wówczas o przedefiniowaniu 

odziedziczonej metody

24

Dziedziczenie pojedyncze i wielokrotne

■

Jeżeli nowa klasa jest podklasą tylko jednej 
klasy bazowej, to taki proces derywacji 
nazywany jest dziedziczeniem pojedynczym. 

■

Jeżeli nowa klasa ma więcej niż jedną 
nadklasę, to proces nazywamy dziedziczeniem 
wielokrotnym.

25

Metody i klasy abstrakcyjne

■

Zdarza się, że klasa jest na tyle wysoko w hierarchii 

dziedziczenia, że nie ma sensu tworzyć dla niej 

instancji. 

■

Podobnie, nie ma sensu implementować metody, 

która jest zbyt wysoko w hierarchii (jako że została już 

zaimplementowana w podklasach). 

■

Taka metoda nazywana jest metodą abstrakcyjną. 

■

Klasa, która zawiera przynajmniej jedną metodę 

abstrakcyjną, nazywana jest klasą abstrakcyjną.

26

Metody i zmienne obiektu i klasy

■

Klasy mogą mieć metody i zmienne instancyjne lub metody 

i zmienne klasowe. 

■

W tym pierwszym przypadku każdy obiekt z danej klasy ma 

swój własny zbiór instancji zmiennych, w których 

przechowywany jest stan obiektu. 

■

W drugim przypadku, metody i zmienne przynależą do całej 

klasy i w klasie jest tylko jedna ich kopia. Mówi się 

o metodach/zmiennych klasowych lub statycznych. 

■

Metody instancyjne są zazwyczaj przechowywane w jednym 

egzemplarzu (tak jak statyczne), ale wywołać je można tylko za 

pomocą instancji obiektu. 

■

Wywołanie metody statycznej nie wymaga powoływania do 

życia instancji obiektu.

27

Polimorfizm i dynamiczne wiązania

■

Zmienne typu klasy bazowej mogą odwoływać 
się także do obiektów dowolnej podklasy tejże 
klasy bazowej. 

■

Nadklasa może definiować metody, które są 
przedefiniowywane przez jej podklasy. 

■

Kiedy taka przedefiniowana metoda jest 
wywoływana przez zmienną klasy bazowej, to 
wywołanie to jest dynamicznie wiązane 
z właściwą metodą. 

■

Jest to rodzaj polimorfizmu: dynamiczne 
wiązanie wywołań z definicjami metod.

28

Polimorfizm

Ptak

poruszaj()

SterownikPtaka

Pingwin

Gęś

poruszaj()

poruszaj()

przemieść()

29

Czy wszystko jest obiektem?

■

W czystym modelu obliczeń zorientowanych obiektowo wszystkie 

typy są klasami. 

■

Nie ma rozróżnienia pomiędzy klasami predefiniowanymi w języku 

a klasami definiowanymi przez użytkownika. 

■

Wszystkie obliczenia realizowane są poprzez przekazywanie 

komunikatów, czyli wywołania metod. 

■

Jest to rozwiązanie eleganckie, ale nawet proste operacje muszą być 

wówczas wykonywane przy użyciu mechanizmu przekazywania 

komunikatów. 

■

Jedną z alternatyw jest zachowanie imperatywnego modelu typów 

i dodanie modelu obiektowego, tak jak np. w C++. To bywa 

kłopotliwe. 

■

Inny pomysł to imperatywna struktura typów dla prostych typów 

skalarnych, a obiektowa dla pozostałych (np. w Javie). To również 

bywa mylące...

30

Czy podklasy są podtypami?

■

Innymi słowy, czy można powiedzieć, że obiekt z podklasy jest też 

obiektem jej klasy bazowej? 

■

Przykład: Mamy klasę zwierzę i dwie podklasy z niej wywiedzione: 

pies i kot. Czy zatem każdy obiekt typu pies jest również obiektem 

typu zwierzę? A co z kotem...? 

■

Owa relacja „bycia obiektem nadklasy” gwarantowałaby, że wszędzie 

tam, gdzie może pojawić się obiekt z klasy bazowej, może się 

również pojawić (bez wystąpienia błędu typu) obiekt z podklasy. 

■

Wywiedziona klasa może być nazwana podtypem, jeżeli jej obiekty 

są w powyższej relacji z klasą bazową. 

■

Podklasa ma w tej sytuacji ograniczone pole manewru: może jedynie 

dodawać zmienne i metody oraz przedefiniowywać dziedziczone 

metody w sposób zapewniający zgodność typów. 

■

Relacje bycia podtypem i dziedziczenia nie są tożsame (do tego 

jeszcze wrócimy).

31

Sprawdzanie zgodności typów i polimorfizm

■

Polimorfizm rozumiemy tu jako użycie polimorficznego wskaźnika 

(referencji) do wywołania metody, która została przedefiniowana w 

jednej z klas pochodnych. 

■

Mówi się także, że metoda została nadpisana. 

■

Owa polimorficzna zmienna (wskaźnik lub referencja) jest typu klasy 

bazowej. W klasie tej znajduje się przynajmniej deklaracja protokołu 

wołanej metody, przedefiniowanej następnie w klasie pochodnej. 

■

Zmienna polimorficzna może wskazywać na obiekty zarówno klasy 

bazowej, jak i pochodnej. Stąd konkretnego typu wskazywanego 

obiektu nie da się określić statycznie. 

■

Wiązanie wywołań realizowanych za pomocą zmiennych 

polimorficznych z metodami musi się zatem odbywać dynamicznie. 

■

Kiedy następuje sprawdzenie zgodności typów dla takiego 

wywołania? 

■

W języku silnie typowanym sprawdzenie powinno być statyczne. W 

konsekwencji trzeba narzucić istotne ograniczenia, np. 

przedefiniowana metoda musi zachować taki sam protokół. 

■

Alternatywą jest dynamiczne sprawdzanie zgodności typów, czyli 

wykonywane dopiero w chwili, gdy następuje wywołanie.

32

Dziedziczenie pojedyncze i wielokrotne

■

Czy język pozwala na dziedziczenie wielokrotne? 

■

Jeśli tak, to jak rozstrzygamy odwołania do bytów (o takiej 

samej nazwie) mających definicje w dwóch klasach 

bazowych? 

■

Rozstrzyganie takich wieloznaczności może być jawne, jak 

np. w C++ za pomocą operatora zakresu ::. 

■

Jeśli ta sama zmienna jest dziedziczona z klasy położonej 

o dwa poziomy wyżej w hierarchii dziedziczenia za 

pośrednictwem dwóch klas bazowych, to czy dziedziczone 

jest jedno wcielenie, czy dwa?

33

■

Załóżmy, że klasa A zawiera pole x: 

       class A {
       ...
       int x;
       ...
     };

■

Dwie klasy, B1 i B2, są podklasami klasy A, dziedzicząc pole x: 

     class B1 : A {...};

     class B2 : A {...};

■

Kolejna klasa, powiedzmy C, jest podklasą dziedziczącą po B1 

i B2: 

     class C : B1, B2 {...};

■

Ile pól x jest zatem w klasie C?

34

Alokacja i dealokacja obiektów

■

Załóżmy, że: 



Klasa B jest podklasą i podtypem klasy A. 



Zmienna xb jest typu B. 



Zmienna xa jest typu A. 

■

Podstawienie „xa := xb” jest zatem prawidłowe. 

■

Zauważmy, że obiekt xb jest większy niż obiekt xa (gdyż może mieć 

dodatkowe pola). 

■

Co zrobić, jeśli obiekt xa jest na stosie i niemożliwe jest powiększenie 

zaalokowanego dla niego obszaru pamięci? 

■

Drugie pytanie, związane z pamięcią: Czy obiekty alokowane na 

stercie są dealokowane jawnie czy niejawnie? 

■

Zauważmy, że dla obiektów alokowanych na stosie ta kwestia nie jest 

istotna: zachowują się one tak samo jak zwykłe zmienne lokalne, 

alokowane przy wejściu do podprogramu i dealokowane przy wyjściu.

35

Wiązanie statyczne i dynamiczne

■

Czy wiązanie wywołań z metodami zawsze jest 
dynamiczne? 

■

Innymi słowy — czy tam, gdzie to możliwe, 
kompilator wiąże wywołania z metodami 
statycznie? 

■

Być może programista powinien mieć 
możliwość wskazania, o jakie wiązanie chodzi.

36

Implementacja konstrukcji obiektowych

■

Dwa zasadnicze problemy: 



Alokacja pamięci dla zmiennych 
instancyjnych. 



Dynamiczne wiązanie wywołań z metodami. 

37

Przechowywanie danych instancyjnych

■

Zmienne należące do instancji obiektu są 
przechowywane w rekordzie instancyjnym. 

■

Jako że jego struktura jest statyczna, jest 
tworzona w czasie kompilacji. 

■

W czasie wykonania struktura ta używana jest 
jako wzorzec do tworzenia danych w 
instancjach. 

■

Podklasy rozszerzają strukturę rekordu 
instancyjnego. 

38

Dynamiczne wiązanie wywołań z metodami 

■

Metody wiązane statycznie nie wymagają 
obsługi w rekordzie instancyjnym. 

■

Metody wiązane dynamicznie, które mogą być 
wywoływane z danej klasy, są zapisane 
w tablicy metod wirtualnych (określanej zwykle 
mianem vtable). 

■

Rekord instancyjny każdego obiektu zawiera 
wskaźnik do vtable. 

■

Podstawienia pod zmienną polimorficzną 
muszą dodatkowo ustawiać odpowiednio ów 
wskaźnik

39

Wielokrotne wykorzystanie 

implementacji

■

Kompozycja – umieszczenie obiektów innych 
klas wewnątrz nowej klasy (tworzenie 
obiektu składowego)

■

Dziedziczenie – utworzenie nowej klasy na 
podstawie klasy już istniejącej – nowa klasa 
przejmuje właściwości klasy bazowej, może 
je modyfikować i dodawać nowe

40

Obiektowe i strukturalne metody analizy

■

Metody strukturalne



Tradycyjne, rozwijane od lat 60-tych XX w.



Wyróżniają w analizowanym systemie dwie składowe:

➔

Pasywne (dane)

➔

Aktywne (operacje)

■

Metody obiektowe



Pojawiły się w latach 80-tych XX w., nadal intensywnie 

rozwijane



Wyróżniają w analizowanym systemie składowe (klasy 

obiektów), które łączą w sobie możliwość 

przechowywania danych (stan obiektu) oraz 

wykonywania pewnych operacji (metody obiektu).

41

Analiza strukturalna

■

Rozpoczyna się od budowy dwóch różnych 
modeli systemu:



Modelu danych (pasywna część systemu)



Modelu funkcji (aktywna część systemu)

■

Te dwa modele są następnie integrowane: 
powstaje model przepływu danych

42

Analiza strukturalna

■

Budowa dwóch różnych modeli systemu 
ułatwia zrozumienie jego różnorodnych 
aspektów

■

Integracja dwóch różnych modeli może być 
bardzo trudna

■

Skuteczne, jeśli jeden z aspektów (pasywny 
lub aktywny) jest wyraźnie bardziej istotny

■

Mało skuteczne, jeśli system ma realizować 
skomplikowane funkcje na złożonych danych

43

Analiza obiektowa

■

Obiekt posiada:



Tożsamość (da się jednoznacznie wyróżnić w 

ramach systemu)



Stan



Zachowanie

■

Obiekty są grupowane w klasy złożone 
z obiektów o podobnych stanach i 
zachowaniu

44

Analiza obiektowa

■

Przyczyny popularności:



Umożliwia analizę złożonych systemów



Ułatwia implementację systemów w obiektowych 

językach programowania



Model  obiektowy  można  zaimplementować  np. 

stosując  języki  proceduralne  i  relacyjną  bazę 

danych



Trudna 

jest 

implementacja 

modelu 

strukturalnego 

w obiektowych 

językach 

programowania

45

Notacje obiektowe

■

Lata 80-te XX w.  – pojawienie się obiektów

■

1988 – 1992 – burzliwy rozwój metod analizy 

obiektowej: OMT (Rumbaugh, 1991), OOA i OOD 

(Coad i Yourdon, 1994), OOAD (Booch, 1994), 

OOSE (Jacobson, 1992) ...

■

1994 – 1995 – Grady Booch i Jim Rumbaugh 

pracują nad Metodą Zunifikowaną

■

1996 – Grady Booch, Jim Rumbaugh i Ivar 

Jacobson pracują nad UML

■

1997 – wersja 1.0 UML

46

UML

■

Zunifikowany Język Modelowania (ang. Unified 

Modeling Language – UML) jest następcą obiektowych 

metod analizy i projektowania, które pojawiły się na 

przełomie lat osiemdziesiątych i dziewięćdziesiątych.

■

Jest standardem OMG (Object Managment Group) – 

organizacji standaryzującej w dziedzinie technik 

obiektowych.

■

Jest językiem modelowania, a nie metodą. Większość 

metod składa się z języka modelowania (notacja 

graficzna) i procesu (kroki projektowania i tworzenia 

oprogramowania).

■

Jest powiązany z Rational Unified Process (RUP)

47

Perspektywy UML

Perspektywa

projektowa

Perspektywa

implementacyjna

Perspektywa

procesowa

Perspektywa

wdrożeniowa

Perspektywa

przypadków

użycia

Słownictwo
Funkcjonalność

Zachowanie

Efektywność
Skalowalność
Przepustowość

Scalanie systemu
Zarządzanie konfiguracją

Opracowanie układu systemu
Rozmieszczenie
Dostarczenie
Instalacja

48

Perspektywa przypadków użycia

W  perspektywie  tej  bierze  się  pod  uwagę 

zachowanie  systemu  widziane  oczami 
użytkowników, 

analityków 

i 

osób 

wykonujących  testy.  Nie  definiuje  się 
rzeczywistej  organizacji  systemu,  a  opisuje 
się 

czynniki 

wpływające 

na 

kształt 

architektury  systemu.  W  UML  aspekty 
statyczne  tej  perspektywy  wyraża  się  za 
pomocą  diagramów  przypadków  użycia,  a 
dynamiczne 

za 

pomocą 

diagramów 

interakcji,  diagramów  stanu  i diagramów 
czynności

49

Perspektywa projektowa

W perspektywie tej kładzie się nacisk na klasy, 

interfejsy  i  kooperacje,  które  razem  składają 
się  na  słownictwo  danego  zadania  i  na 
rozwiązanie  tego  zadania.  Perspektywa  ta 
pomaga 

w zapisywaniu 

wymagań 

funkcjonalnych,  czyli  usług,  które  system 
powinien  udostępniać  swoim  użytkownikom. 
W  UML  aspekty  statyczne  tej  perspektywy 
wyraża  się  za  pomocą  diagramów  klas  i 
diagramów  obiektów,  a  dynamiczne  za 
pomocą  diagramów  interakcji,  diagramów 
stanów i diagramów czynności.

50

Perspektywa procesowa

W perspektywie tej zwraca się uwagę na wątki 

i procesy,  które  kształtują  mechanizmy 
współbieżności  i  synchronizacji  w  systemie. 
Dotyczy 

ona 

głównie 

efektywności, 

skalowalności  i  przepustowości  systemu. 
W UML  aspekty  statyczne  i  dynamiczne  tej 
perspektywy  są  przedstawiane  na  takich 
samych  rodzajach  diagramów  jak  w 
przypadku  perspektywy  projektowej,  z  tą 
tylko różnicą, że główny nacisk kładzie się na 
klasy  aktywne,  które  reprezentują  procesy  i 
wątki.

51

Perspektywa implementacyjna

W 

perspektywie 

tej 

znaczenie 

mają 

komponenty  i pliki,  użyte  do  scalenia  i 
udostępnienia systemu fizycznego. Wiąże się 
ona 

z 

zarządzaniem 

konfiguracją 

poszczególnych wersji systemu, złożonych z 
rozmaitych  niezależnych  komponentów  i 
plików,  które  można  zepolić  na  wiele 
sposobów,  aby  otrzymać  działający  system. 
W  UML  aspekty  statyczne    tej  perspektywy 
wyraża 

się 

za 

pomocą 

diagramów 

komponentów,  a  dynamiczne  za  pomocą 
diagramów  interakcji,  diagramów  stanów  i 
diagramów czynności.

52

Perspektywa wdrożeniowa

W perspektywie tej kładzie się nacisk na węzły, 

składające  się  na  sprzęt,  na  którym  system 
będzie  uruchamiany.  Wiąże  się  ona  głównie 
z rozmieszczeniem, 

dostarczeniem 

i 

instalacją  części  systemu  fizycznego.  W 
UML  aspekty  statyczne  tej  perspektywy 
wyraża  się  za  pomocą  diagramu  wdrożenia, 
a  dynamiczne  za  pomocą  diagramów 
interakcji,  diagramów  stanów  i diagramów 
czynności.

53

Perspektywy UML (II)

■

Pojęciowa

Reprezentuje  pojęcia  analizowanej  dziedziny. 

Pojęcia  te  będą 

związane  z klasami  je  implementującymi,  ale  często  nie  będzie  między  nimi 
pełnej  odpowiedniości.  Model  pojęciowy  powinien  być  tworzony  niezależnie  od 

oprogramowania, które może implementować ten model, tak aby można go było 

traktować jako niezależny językowo.

■

Specyfikacyjna

Dotyczy  już  oprogramowania,  ale  raczej  interfejsów  niż 

implementacji. 

Mimo  że  programowanie  obiektowe  kładzie  duży  nacisk  na 

różnicę  między  interfejsem  a  implementacją,  to  w  praktyce  często  się  o  tym 

zapomina,  bo  pojęcie  klasy  w  językach  programowania  obiektowego  łączy 

pojęcia  interfejsu  i  implementacji.  Nie  powinno  tak  być  –  kluczem  do 
efektywnego  programowania  obiektowego  jest  programowanie  sterowane 

interfejsem klasy, a nie sposobem implementacji.

■

Implementacyjna

Dokładnie  ukazuje  całą  implementację.

 

Jest  to  prawdopodobnie 

najczęściej  używana  perspektywa,  ale  w  wielu  przypadkach  lepiej  przyjąć 

perspektywę specyfikacyjną.

54

Rodzaje diagramów UML

■

Diagramy struktury
służą do obrazowania, specyfikowania, 
tworzenia i dokumentowania statycznych 
aspektów systemu

■

Diagramy zachowania
służą do obrazowania, specyfikowania, 
tworzenia i dokumentowania dynamicznych 
aspektów systemu

55

Rodzaje diagramów UML

■

Diagramy struktury



Diagram klas



Diagram obiektów



Diagram pakietów



Diagramy fizyczne

➔

Diagram komponentów

➔

Diagram wdrożenia

■

Diagramy zachowania



Diagram przypadków użycia



Diagramy interakcji

➔

Diagram przebiegu (sekwencji)

➔

Diagram kooperacji (współdziałania)



Diagram stanów



Diagram czynności

56

Diagram klas

Na  diagramie  klas  mogą  znaleźć  się  klasy, 

interfejsy,  kooperacje  i  związki  między  nimi. 
Jest  to  najczęściej  spotykany  diagram  w 
modelach  obiektowych.  Odnosi  się  do 
statycznych 

aspektów 

perspektywy 

projektowej.  Diagram  klas  uwzględniający 
klasy aktywne dotyczy statycznych aspektów 
perspektywy procesowej.

57

Diagram klas

■

Opisuje  typy  obiektów  w  systemie  i  różne 
rodzaje  statycznych  relacji  między  nimi.  Są 
dwa główne rodzaje relacji statycznych:



asocjacje  (np.  klient  może  wypożyczyć  kilka 

kaset wideo)



podtypy (np. pielęgniarka jest osobą)

■

Diagram  klas  pokazuje  również  atrybuty 
i operacje klas oraz ograniczenia tego, w jaki 
sposób obiekty mogą być powiązane.

58

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

59

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

klasa

60

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

atrybuty

61

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

operacj

e

62

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

uogólnienie

Diagramy klas

63

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

asocjacja

Diagramy klas

64

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

Krotność: 

obowiązkowe

Diagramy klas

65

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

Krotność: 

wiele

66

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

Krotność: 

opcjonalny

67

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

Nazwa roli

68

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

ograniczeni

e

Diagramy klas

69

Diagramy klas

Zamówienie

DataOtrzymania
przedpłata
numer: String
cena: waluta

wyślij()
zamknij()

Klient

nazwa
adres

WiarygodnośćKredytowa(): String

Klient firmowy

osobaDoKontaktów
wiarygodnośćKredytowa
limitKredytowy

przypomnij()
obciążZaMiesiąc(Integer)

Klient indywidualny

numerKartyKredytowej

Pozycja zamówienia

ilość: Integer
cena: waluta
zapewniona: Boolean

Pracownik

Towar

*

0..1

*

1

*

1

1

*

pozycje

przedstawiciel
handlowy

{wiarygodnośćKredytowa()
== „niska”}

{jeśli Zamówienie.klient.
wiarygodnośćKredytowa

jest „niska”, to Zamówienie.
przedpłata musi być
prawdziwe}

nawigowalność

70

Diagram obiektów

Element struktury

organizacyjnej

siedziba

Osoba

Organizacja

* dzieci

1 rodzic

■

Diagram obiektów jest obrazem obiektów 
w systemie w określonej chwili

■

Jest bardzo przydatny, gdy możliwe 
powiązania między obiektami są 
skomplikowane

71

Diagram obiektów

Element struktury

organizacyjnej

siedziba

Osoba

Organizacja

* dzieci

1 rodzic

dział oprogramowania: Organizacja

siedziba = „Warszawa”

narzędzia: Organizacja

siedziba = „Poznań”

aplikacje: Organizacja

siedziba = „Paryż”

Anna: Osoba

siedziba = „Kraków”

Jan: Osoba

siedziba = „Kraków”

rodzic

rodzic

72

Operacje i atrybuty w zasięgu klasy

Zamówienie

pobierzNumer()
pobierzNastępnyNowyNumer()

zasięg

instancji

zasięg

klasy

■

UML określa operację lub atrybut, których 
obszar działania to klasa, a nie instancja tej 
klasy, jako będące w zasięgu klasy.

■

Jest to równoważne statycznym składowym 
w C++ lub Javie

73

Klasyfikacja wielokrotna

Osoba

Kobieta

Mężczyzna

Pacjent

Lekarz

Pielęgniarz

Fizjo-

terapeuta

Chirurg

Lekarz

domowy

Pacjent

Rola

Płeć
{complete}

wyróżnik

74

Klasyfikacja dynamiczna

Osoba

Kobieta

Mężczyzna

Lekarz

Pielęgniarz

Fizjo-

terapeuta

Płeć
{complete}

Zawód
<<dynamiczna>>

75

Agregacja i zawieranie

Styl

kolor
jestWypełniony

Wielokąt

Punkt

Koło

promień

{ordered}

3..*

*

1

1

1

*

zawieranie

agregacja

76

Alternatywna notacja dla zawierania

Styl

Koło

Punkt

*

1

1

1

*

Wielokąt

Punkt

{ordered} 3..*

Koło

Punkt

1

77

Asocjacje i atrybuty pochodne

Rachunek

skrócony

Rachunek

/saldo: Waluta

komponenty

{hierarchy}

1

*

Zapis

wartość: Waluta

Rachunek

szczegółowy

Rola zapisów pochodzi

z komponenty.zapisy

/Zapisy

*

0..1

{saldo = suma wartości zapisów}

asocjacja

pochodna

atrybut

pochodny

uwaga

78

Klasy abstrakcyjne

Okno

{abstract}

Edytor

tekstów

pierwszyPlan()
ostatniPlan()

Okno w Windows

pierwszyPlan()
ostatniPlan()

Okno w X11

pierwszyPlan()
ostatniPlan()

Okno w MacIntoshu

pierwszyPlan()
ostatniPlan()

zależność

79

Klasy abstrakcyjne

<<interface>>

DataInput

CzytnikZamówień

DataInputStream

InputStream

zależność

realizacja

uogólnienie

80

Notacja „lizakowa”

CzytnikZamówień

DataInputStream

DataInput

InputStream

interfejs

zależność

81

Zbiory dla wielokrotnych stron asocjacji

■

Strona wielokrotna asocjacji to ta, której 
górne ograniczenie krotności jest większe niż 
1(na przykład *)

■

Zwykle strony wielokrotne traktujemy jako 
zbiory (nieuporządkowane, nie powtarzają 
się)

■

Inne możliwości:



{ordered}



{bag}



{hierarchy}



{dag}

82

Asocjacje kwalifikowane

Pozycja zamówienia

Towar

Ilość: Liczba

Zamówienie

0..1

Pozycja

83

Klasy asocjacyjne

Zatrudnienie

okres: zakresDat

Osoba

0..1

Pracodawca

Przedsiębiorstwo

*

84

Klasy asocjacyjne

Zatrudnienie

okres: zakresDat

Osoba

0..1

/Pracodawca

Przedsiębiorstwo

*

*

0..1

1

1

85

Klasy asocjacyjne

Zatrudnienie

okres: zakresDat

Osoba

*

Pracodawca

Przedsiębiorstwo

*

86

Klasy asocjacyjne

Kwalifikacje

poziom

Osoba

Umiejętności

*

*

87

Klasy asocjacyjne

Osoba

0..1

Pracodawca

<<history>>

Przedsiębiorstwo

*

88

Klasy parametryzowane

Zbiór

wstaw(T)
usuń(T)

T

Zbiór<Pracownik>

Zbiór

wstaw(T)
usuń(T)

T

ZbiórPracowników

<<bind>>

<Pracownik>