Inżynieria oprogramowania
wykład V
prowadzący: dr inż. Krzysztof Bartecki
W niniejszym opracowaniu wykorzystano materiały dydaktyczne ze strony
projektu  Opracowanie programów nauczania na odległość na kierunku
studiów wyższych  Informatyka autorstwa p. Bartosza Waltera
http://wazniak.mimuw.edu.pl
Faza analizy systemowej  ciąg dalszy
Wymagania Projektowanie Implementacja
Testowanie Konserwacja
Instalacja
Strategiczna Analiza
Dokumentacja
Przypomnienie:
Jej celem jest udzielenie odpowiedzi na pytanie: jak system ma działać?
W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujący
sposób realizacji przez system postawionych wymagań, lecz abstrahujący
od szczegółów implementacyjnych.
K. Bartecki, Inżynieria oprogramowania, V/3
Analiza obiektowa
Popularność obiektowych metod analizy ściśle wiąże się
z rosnącą popularnością obiektowych środowisk implementacji.
Programowanie obiektowe ułatwia:
Programowanie obiektowe ułatwia:
ukrywanie (hermetyzację) danych (ang. data encapsulation),
wykorzystanie gotowych elementów,
ponowne wykorzystanie oprogramowania (ang. software reuse),
szybkie prototypowanie (ang. rapid prototyping),
programowanie oparte na zdarzeniach (ang. event-driven
programming).
K. Bartecki, Inżynieria oprogramowania, V/4
Na początku lat 90. ubiegłego wieku istniało wiele notacji i metodyk analizy
obiektowej, stosujących elementy o zbliżonej semantyce (np. pojęcie klasy),
ale różniące się sposobem ich reprezentacji.
Należały do nich m.in.:
OMT (ang. Object Modelling Technique), J. Rumbaugh, 1991;
OOSE (ang. Object-Oriented Software Engineering), I. Jacobson, 1992;
OOSE (ang. Object-Oriented Software Engineering), I. Jacobson, 1992;
OOAD (ang. Object-Oriented Analysis and Design), G. Booch, 1994;
OOA, OOD (ang. Object-Oriented Analysis, Object-Oriented Design),
P. Coad i E. Yourdon, 1994.
Około roku 1995 Booch, Jacobson i Rumbaugh ("trzej amigos") podjęli
działania nad ujednoliceniem swoich notacji, tworząc jedną metodę  tak
powstał UML (zunifikowany język modelowania).
K. Bartecki, Inżynieria oprogramowania, V/5
UML 2.2
UML 2.2
2009
K. Bartecki, Inżynieria oprogramowania, V/6
 Drzewo genealogiczne języka UML
K. Bartecki, Inżynieria oprogramowania, V/7
K. Bartecki, Inżynieria oprogramowania, V/8
UML zawiera dwie podstawowe składowe:
notację poszczególnych elementów używanych na diagramach,
metamodel, czyli definicje pojęć języka i powiązania między nimi.
Z punktu widzenia analityka istotniejsze jest czytelne i jednoznaczne
opisanie modelu tak, aby inne osoby mogły zrozumieć jego znaczenie.
opisanie modelu tak, aby inne osoby mogły zrozumieć jego znaczenie.
Zatem ważniejsza dla niego jest notacja, zaś metamodel powinien być
zrozumiały intuicyjnie.
Z kolei przy generowaniu kodu i przejściu do implementacji, ważniejsze
jest ścisłe rozumienie znaczenia poszczególnych elementów  czyli
metamodel.
K. Bartecki, Inżynieria oprogramowania, V/9
W najnowszej wersji UML (2.2) wyróżnia się 14 rodzajów diagramów,
podzielonych na dwie główne grupy:
diagramy opisujące strukturę systemu (ang. structure diagrams),
diagramy opisujące zachowanie systemu (ang. behavior diagrams).
K. Bartecki, Inżynieria oprogramowania, V/10
Diagramy struktury:
diagram klas (ang. class diagram),
diagram obiektów (ang. object diagram),
diagram komponentów (ang. component diagram),
diagram wdrożeniowy (ang. deployment diagram),
diagram wdrożeniowy (ang. deployment diagram),
diagram pakietów (ang. package diagram)  od UML 2.0,
diagram struktur złożonych (ang. composite structure diagram)  od
UML 2.0,
diagram profili (ang. profile diagram)  od UML 2.2.
K. Bartecki, Inżynieria oprogramowania, V/11
Diagramy dynamiki:
diagram przypadków użycia (ang. use case diagram),
diagram czynności (ang. activity diagram),
diagram maszyny stanowej (ang. state machine diagram)  wcześniej
nazywany diagramem stanów,
W ramach diagramów dynamiki wyróżnia się tzw. diagramy interakcji:
diagram sekwencji (ang. sequence diagram),
diagram komunikacji (ang. communication diagram)  wcześniej
nazywany diagramem współpracy,
diagram zależności czasowych (ang. timing diagram),
diagram przeglądu interakcji (ang. interaction overview diagram).
K. Bartecki, Inżynieria oprogramowania, V/12
W praktyce rzadko wymagane jest opracowywanie wszystkich diagramów.
Projektując system informatyczny, rozpoczyna się przeważnie od tworzenia
diagramów w następującej kolejności:
1. Przypadków użycia
1. Przypadków użycia
2. Sekwencji
3. Klas
4. Aktywności
Są to najczęściej wykorzystywane diagramy. Pozostałe bywają pomijane,
zwłaszcza przy budowaniu niewielkich systemów informatycznych.
K. Bartecki, Inżynieria oprogramowania, V/13
Przykładowe diagramy języka UML
K. Bartecki, Inżynieria oprogramowania, V/14
Diagram przypadków użycia
definiuje granice modelowanego systemu,
określa jego kontekst,
wymienia użytkowników systemu, odbiorców efektów pracy systemu
i jednostki zewnętrzne (tzw. aktorów),
przedstawia główne funkcje systemu dostępne dla użytkowników (tzw.
przypadki użycia),
określa powiązania i zależności pomiędzy aktorami i przypadkami użycia
oraz między przypadkami użycia a innymi przypadkami użycia.
K. Bartecki, Inżynieria oprogramowania, V/15
Graficzna notacja przypadku użycia
wystawianie faktury
sprzedawca
przypadek użycia
aktor asocjacja
K. Bartecki, Inżynieria oprogramowania, V/16
Diagram przypadków użycia opisuje system z punktu widzenia użytkownika,
pokazuje co robi system, a nie jak to robi.
Diagram ten zazwyczaj nie daje nam zbyt wielu informacji, dlatego też
zawsze potrzebna jest do niego dokumentacja w postaci dobrze
napisanego przypadku użycia  patrz wykład II.
K. Bartecki, Inżynieria oprogramowania, V/17
K. Bartecki, Inżynieria oprogramowania, V/18
Aktor  właściwości
Aktor jest osobą (lub dowolną inną jednostką), która wymienia informacje
z systemem, choć pozostaje poza jego zakresem.
Aktor jest w szerokim znaczeniu użytkownikiem tego systemu, żądając
od systemu wykonania pewnych funkcji lub odbierając efekty ich
wykonania.
Aktor opisuje rolę, a nie konkretną osobę lub jednostkę.
Aktor opisuje rolę, a nie konkretną osobę lub jednostkę.
Aktorzy są powiązani z przypadkami użycia, z których korzystają.
Aktorzy mogą być powiązani również ze sobą relacją uogólnienia/
uszczegółowienia: w ten sposób zachowanie bardziej ogólnego aktora
jest dziedziczone przez aktora bardziej szczegółowego.
Przykładami aktorów w systemie bibliotecznym mogą być Bibliotekarz
i Czytelnik, ale także Zegar, który cyklicznie wysyła komunikat
powodujący wyszukanie książek o przekroczonym terminie zwrotu.
K. Bartecki, Inżynieria oprogramowania, V/19
K. Bartecki, Inżynieria oprogramowania, V/20
Przypadek użycia  właściwości
Przypadek użycia reprezentuje zamkniętą i kompletną funkcjonalność
dostępną dla aktora  stanowi zbiór akcji wykonywanych przez system,
które powodują efekt zauważalny dla aktora.
Przypadki użycia zawsze muszą być inicjowane (bezpośrednio lub przez
zależności) przez aktora i wykonywane w jego imieniu.
zależności) przez aktora i wykonywane w jego imieniu.
Przypadek użycia musi być kompletny, to znaczy w pełni realizować
podaną funkcjonalność oraz dostarczać wyniki aktorowi.
Przypadki użycia komunikują się z aktorami poprzez powiązania
pokazujące, który aktor ma dostęp do podanego przypadku użycia.
Ponadto przypadki użycia mogą być powiązane pomiędzy sobą
relacjami: uogólnienia, rozszerzenia i zawierania.
K. Bartecki, Inżynieria oprogramowania, V/21
Najczęściej popełniane błędy
Zewnętrzny katalog szkoleń
Wykładowca
Wybór szkolenia
Wystawienie ocen
Nowa baza danych
Zdefiniowanie wewnętrznego magazynu danych jako aktora
K. Bartecki, Inżynieria oprogramowania, V/22
Wybór szkolenia
Zewnętrzny katalog szkoleń
Wykładowca
Brak przypisania aktora do przypadku użycia
Każdy aktor musi wchodzić w interakcję z przynajmniej jednym
przypadkiem użycia, oraz z każdego przypadku użycia musi korzystać
(bezpośrednio lub pośrednio) przynajmniej jeden aktor.
K. Bartecki, Inżynieria oprogramowania, V/23
1..n
n=5000
Logowanie
Student
Przedstawienie na diagramie wymagań niefunkcjonalnych
Fakt, że równocześnie w systemie powinno móc pracować do 5000
zalogowanych studentów odnosi się do wydajności systemu i nie
powinien być pokazywany na powyższym diagramie.
K. Bartecki, Inżynieria oprogramowania, V/24
Zarządzanie danymi wykładowców
<>
Referent
Usuwanie danych wykładowcy
<>
<>
Zmiana danych wykładowcy
Dodawanie danych wykładowcy
Dodawanie danych wykładowcy
Niepoprawne użycie związku zawierania
Związek zawierania <> oznacza, że bazowy przypadek
użycia automatycznie rozszerzany jest o dodatkową funkcjonalność.
Z powyższego diagramu wynika zatem, że za każdym razem, gdy
Referent zarządza danymi wykładowców, to musi dodać dane
wykładowcy, zmienić je oraz usunąć.
K. Bartecki, Inżynieria oprogramowania, V/25
Przykładowy diagram przypadków użycia
K. Bartecki, Inżynieria oprogramowania, V/26
Scenariusz przypadku użycia
tekstowy opis kroków (ciągu zdarzeń), które składają się na dany
przypadek,
przypadek,
sekwencja zdarzeń w systemie oraz opis interakcji użytkownika
(obiektu zewnętrznego) z systemem,
napisany tak, aby był zrozumiały nawet dla osoby nie znającej się na
projektowaniu systemów informatycznych (pt. widzenia użytkownika,
w szczególności klienta).
K. Bartecki, Inżynieria oprogramowania, V/27
Elementy scenariusza przypadku użycia
1. Nazwa przypadku użycia
2. Nazwa aktora głównego
3. Nazwa aktora wtórnego (opcjonalnie)
4. Opis przypadku użycia
5. Warunki wstępne
6. Przebieg główny (podstawowy)
7. Przebiegi alternatywne (opcjonalnie)
8. Sytuacje wyjątkowe (opcjonalnie)
9. Warunki końcowe
10. Wymagania niefunkcjonalne (opcjonalnie)
K. Bartecki, Inżynieria oprogramowania, V/28
Nazwa Dodaj do koszyka
Aktor Klient
Opis Funkcja umożliwia dodanie produktu do koszyka klienta
Warunek
Klient musi być zalogowany w systemie
wstępny
1. Klient wybiera produkt z oferty systemu
2. Klient uruchamia funkcję  Dodaj do Koszyka
Przebieg
3. Klient wpisuje ilość zamawianych produktów
główny
4. System sprawdza poprawność wprowadz. produktów i zapisuje w koszyku
5. System wyświetla zawartość koszyka
5. System wyświetla zawartość koszyka
2a) Gdy klient nie jest zalogowany, system wyświetla odp. komunikat
2b) Klient nie dodaje produktu do koszyka
3a) Klient podaje większą ilość produktu niż jego ilość w ofercie,
Przebiegi
system wyświetla komunikat o błędzie
alternatywne
3b) Gdy produkt nie jest dostępny w systemie, system wyświetla komunikat
 Brak produktu
4a) Klient usuwa produkt z koszyka
Warunek
Produkt znajduje się w koszyku klienta
końcowy
Przykładowy scenariusz przypadku użycia  Dodaj do koszyka
K. Bartecki, Inżynieria oprogramowania, V/29
Przykładowy scenariusz przypadku użycia  Wypłać pieniądze
K. Bartecki, Inżynieria oprogramowania, V/30
Diagram klas
jest podstawowym diagramem struktury logicznej systemu,
przedstawia występujące w systemie klasy i zachodzące pomiędzy nimi
statyczne relacje,
statyczne relacje,
klasy na diagramie reprezentowane przez prostokąty  mogą one
zawierać informację o danych składowych (atrybutach) i operacjach
klasy,
spośród wszystkich diagramów UML jest najbardziej  pojemny i z tego
względu jest najczęściej stosowany do generowania kodu na podstawie
modelu.
K. Bartecki, Inżynieria oprogramowania, V/31
Tworzenie diagramu klas obejmuje:
identyfikację klas i obiektów,
identyfikację związków pomiędzy klasami,
identyfikację i definiowanie pól (atrybutów),
identyfikację i definiowanie metod i komunikatów.
Kolejność wykonywania tych czynności nie jest ściśle ustalona i zależy
zarówno od stylu pracy, jak i od konkretnego problemu.
K. Bartecki, Inżynieria oprogramowania, V/32
Przykładowy diagram klas
K. Bartecki, Inżynieria oprogramowania, V/33
Klasa jest reprezentowana na diagramie przez prostokąt z wydzielonymi
przedziałami: nazwą, atrybutami i operacjami.
K. Bartecki, Inżynieria oprogramowania, V/34
Cechy klasy
reprezentują informację, jaką klasa przechowuje,
mogą zostać zapisane w postaci dwóch równoważnych notacji:
 jako atrybuty klasy (umieszczane w przedziale atrybutów),
 jako relacje pomiędzy klasami (zapisywane w postaci linii łączącej
klasy).
zwykle pierwsza notacja jest stosowana do typów prostych lub obiektów
zwykle pierwsza notacja jest stosowana do typów prostych lub obiektów
reprezentujących wartości, natomiast druga do typów złożonych.
Operacje klasy
reprezentują usługi, jakie klasa oferuje,
realizacje operacji  czyli metody  dostarczają implementacji tych
usług.
K. Bartecki, Inżynieria oprogramowania, V/35
Atrybut
zwykle jest opisywany tylko przez dwa elementy: nazwę i typ.
Jednak pełna jego definicja może obejmować także dodatkowe informacje:
K. Bartecki, Inżynieria oprogramowania, V/36
K. Bartecki, Inżynieria oprogramowania, V/37
K. Bartecki, Inżynieria oprogramowania, V/38
K. Bartecki, Inżynieria oprogramowania, V/39
K. Bartecki, Inżynieria oprogramowania, V/40
K. Bartecki, Inżynieria oprogramowania, V/41
Operację można także opisywać przez dwa rodzaje warunków: wstępne
i końcowe. Opisują one wymagany i oczekiwany stan fragmentu systemu
wymagany odpowiednio przed i po wykonaniu operacji.
K. Bartecki, Inżynieria oprogramowania, V/42
Związki klas
to ogólne określenie relacji zachodzących między klasami, gdy jedna
z nich w pewien sposób  używa innej klasy.
Diagramy klas mogą uwzględniać następujące rodzaje związków:
Diagramy klas mogą uwzględniać następujące rodzaje związków:
zależność (ang. dependency),
asocjacja (ang. association),
agregacja (ang. aggregation),
kompozycja (ang. composition),
generalizacja-specjalizacja (ang. generalization-specialization).
K. Bartecki, Inżynieria oprogramowania, V/43
K. Bartecki, Inżynieria oprogramowania, V/44
Właściwości związku zależności
Zależność pomiędzy dwiema klasami informuje, że jedna z nich, aby
używać obiektów innej, musi mieć o niej informacje.
Zależność występuje, gdy zmiana specyfikacji jednej klasy, może
powodować konieczność wprowadzania zmiany w innej klasie.
Najczęściej używa się zależności do pokazania, że jedna klasa używa
innej jako parametru jakiejś operacji.
Obie klasy są zależne od siebie nawzajem w celu zapewnienia
Obie klasy są zależne od siebie nawzajem w celu zapewnienia
poprawnego działania systemu.
Zależności często opisuje się frazami:  korzysta z ,  oddziałuje na ,  ma
wpływ na ,  tworzy .
K. Bartecki, Inżynieria oprogramowania, V/45
K. Bartecki, Inżynieria oprogramowania, V/46
Właściwości związku asocjacji
Asocjacje są relacjami silniejszymi niż zależności  wskazują, że jeden
obiekt jest związany z innym przez pewien okres czasu, jednak czas
życia obu obiektów nie jest od siebie zależny: usunięcie jednego nie
powoduje usunięcia drugiego.
W przypadku asocjacji żaden obiekt nie jest właścicielem drugiego: nie
W przypadku asocjacji żaden obiekt nie jest właścicielem drugiego: nie
tworzy go, nie zarządza nim, a moment usunięcia drugiego obiektu nie
jest z nim związany.
Asocjacje mogą posiadać nazwy, zwykle w formie czasownika,
pozwalającego przeczytać w języku naturalnym jej znaczenie, np.
 A posiada B .
K. Bartecki, Inżynieria oprogramowania, V/47
Właściwości związku asocjacji  c.d.
Asocjacja jest równoważna atrybutowi: UML nie rozróżnia obiektu, który
jest polem klasy od obiektu i jest z nią związany asocjacją.
Przyjmuje się konwencję, w której obiekty reprezentujące wartości (np.
daty) oraz typy proste (liczby, napisy, znaki) są modelowane jako
atrybuty, natomiast obiekty dostępne poprzez referencje  są
przedstawiane poprzez asocjacje.
Przykład związku
asocjacji
K. Bartecki, Inżynieria oprogramowania, V/48
Krotność danego końca asocjacji to dopuszczalna liczba obiektów klasy
znajdującej się przy tym końcu, skojarzonych z jednym obiektem klasy na
drugim końcu tej asocjacji.
Krotności są pojedynczymi liczbami albo zakresami liczb:
Krotność Znaczenie
0 .. 1 Brak obiektu lub jeden obiekt.
0 .. * Bez ograniczenia liczby obiektów
(łącznie z ich brakiem).
1 Dokładnie jeden obiekt.
1 .. * Przynajmniej jeden obiekt.
n Dokładnie n obiektów.
m .. n Od m do n obiektów.
K. Bartecki, Inżynieria oprogramowania, V/49
Przykłady krotności
1
K. Bartecki, Inżynieria oprogramowania, V/50
K. Bartecki, Inżynieria oprogramowania, V/51
Nawigowalność (asocjacje skierowane)
Nawigowalność pomiędzy klasą A i klasą B oznacza, że od obiektu
klasy A można przejść do obiektu klasy B, ale nie odwrotnie.
Nawigowalność dwukierunkowa oznacza, że nawigując od obiektu klasy
A do obiektu klasy B, a następnie z powrotem, w zbiorze wyników
A do obiektu klasy B, a następnie z powrotem, w zbiorze wyników
można znalez
ć początkowy obiekt klasy A.
Nawigowalność oznaczana jest na diagramach strzałką.
W przypadku nawigowalności dwukierunkowej strzałki pomija się.
K. Bartecki, Inżynieria oprogramowania, V/52
Przykłady implementacji asocjacji skierowanych w kodzie języka C++
Klient
Zamówienie
składanie
1..1
- nr klienta : int
- nr zamówienia : int
0..*
- nazwisko : std::string
- kwota zamówienia : float
class Zamowienie
class Klient
class Klient
{
{
public:
public:
protected:
protected:
private:
private:
Klient* klient;
int nrklienta;
int nr_zamowienia;
std::string nazwisko;
float kwota_zamowienia;
};
};
K. Bartecki, Inżynieria oprogramowania, V/53
Klient
Zamówienie
składanie
1..1
- nr klienta : int
- nr zamówienia : int
0..*
- nazwisko : std::string
- Kwota zamówienia : float
class Zamowienie
class Klient
class Klient
{
{
public:
public:
protected:
protected:
private:
private:
int nr_zamowienia;
std::list zamowienie;
float kwota_zamowienia;
int nr_klienta;
};
std::string nazwisko;
};
K. Bartecki, Inżynieria oprogramowania, V/54
Asocjacja dwukierunkowa
Klient
Zamówienie
składanie
1..1
- nr klienta : int
- nr zamówienia : int
0..*
- nazwisko : std::string
- Kwota zamówienia : float
class Zamowienie
class Klient
class Klient
{
{
public:
public:
protected:
protected:
private:
private:
Klient* klient;
std::list zamowienie;
int nr_zamowienia;
int nr_klienta;
float kwota_zamowienia;
std::string nazwisko;
};
};
K. Bartecki, Inżynieria oprogramowania, V/55
K. Bartecki, Inżynieria oprogramowania, V/56
Klasa asocjacyjna  właściwości
Klasa asocjacyjna umożliwia opisanie za pomocą atrybutów i operacji
nie obiektu, ale samej asocjacji pomiędzy klasami.
Informacje przechowywane w klasie asocjacyjnej nie są związane
Informacje przechowywane w klasie asocjacyjnej nie są związane
z żadną z klas uczestniczących w asocjacji, dlatego wygodnie jest
stworzyć dodatkową klasę i powiązać ją z relacją asocjacji.
Klasa asocjacyjna na etapie modelowania logicznego może zostać
przekształcona do postaci  zwykłej (nieasocjacyjnej) klasy.
K. Bartecki, Inżynieria oprogramowania, V/57
Zamiana klasy asocjacyjnej
w  zwykłą klasę na diagramie implementacyjnym
K. Bartecki, Inżynieria oprogramowania, V/58
K. Bartecki, Inżynieria oprogramowania, V/59
Asocjacja kwalifikowana  właściwości
Asocjacja kwalifikowana jest rozszerzeniem zwykłej asocjacji
o możliwość określenia, który z atrybutów jednej z klas decyduje
o związku między tymi klasami.
Na przykład, składając Rezerwację, Czytelnik podaje listę
Wydawnictw, które chciałby wypożyczyć  występuje tu relacja typu
 wiele do jednego .
 wiele do jednego .
Jednak w danym momencie Czytelnik może zarezerwować dane
Wydawnictwo tylko jeden raz  i dlatego atrybut id Wydawnictwa jest
kwalifikatorem tej relacji.
W efekcie pomiędzy instancją Czytelnika a instancją Rezerwacji
występuje relacja  jeden do jednego , ponieważ konkretny Czytelnik
rezerwuje konkretne Wydawnictwo w danym momencie tylko raz.
K. Bartecki, Inżynieria oprogramowania, V/60
K. Bartecki, Inżynieria oprogramowania, V/61
Agregacja  właściwości
Agregacja jest silniejszą formą asocjacji,
agregacja to związek, w którym jedna z klas należy do kolekcji,
której właścicielem jest obiekt innej klasy (np. Klasa może stanowić
agregację Uczniów),
w przypadku agregacji istnieje właściciel i obiekt podrzędny (obiekty
podrzędne), które są ze sobą powiązane czasem swojego życia,
podrzędne), które są ze sobą powiązane czasem swojego życia,
właściciel jednak nie jest wyłącznym właścicielem obiektu
podrzędnego, zwykle też nie tworzy i nie usuwa go.
K. Bartecki, Inżynieria oprogramowania, V/62
K. Bartecki, Inżynieria oprogramowania, V/63
Kompozycja  właściwości
Kompozycja jest najsilniejszą relacją łączącą klasy,
reprezentuje relacje całość-część, w których części są tworzone
i zarządzane przez obiekt reprezentujący całość,
ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich
istnienia są bardzo ściśle ze sobą związane i pokrywają się,
w momencie usunięcie obiektu całości obiekty części są również
usuwane.
usuwane.
K. Bartecki, Inżynieria oprogramowania, V/64
Agregacja i kompozycja  przykłady implementacji w C++
class University class Department class Professor
{ { {
{ { {
private: private: private:
std:string univName std::string depName; std::string profName;
Department faculty[20]; University* univ; Department*
create_dept() Professor* members[5]; affiliation[];
{ ... ...
// Composition }; };
faculty[0]=Department(..);
faculty[1]=Department(..);
...
}
};
K. Bartecki, Inżynieria oprogramowania, V/65
K. Bartecki, Inżynieria oprogramowania, V/66
Uogólnienie (generalizacja-specjalizacja)  właściwości
Jest to związek występujący między klasą bardziej ogólną (nadklasą,
rodzicem, generalizacją) a klasą bardziej szczegółową (podklasą,
dzieckiem, specjalizacją),
podklasa jest w pełni zgodna z klasą nadrzędną i ponadto zawiera
dodatkowe cechy i/lub operacje,
uogólnienie często jest traktowane jako synonim dziedziczenia.
K. Bartecki, Inżynieria oprogramowania, V/67
Przykład złożonej hierarchii generalizacji-specjalizacji
K. Bartecki, Inżynieria oprogramowania, V/68
Dziedziczenie wielokrotne  przykład w kodzie języka C++
class Samochod {
int liczbaKol;
public:
Samochód
A
ódz

void jedz() { /* ciało metody */ }
};
class Lodz {
float wypornosc;
public:
Amfibia
void plyn() { /* ciało metody */ }
};
};
class Amfibia : public Samochod, public Lodz {
std::string nrRejestracyjny;
};
void napompujKolo(Samochod& samochod) { /* ciało metody */ }
void naprawKadlub(Lodz& lodz) { /* ciało metody */ }
int main() {
Amfibia amfibia;
napompujKolo(amfibia);
naprawKadlub(amfibia);
return 0;
}
K. Bartecki, Inżynieria oprogramowania, V/69
Klasa abstrakcyjna
Klasa abstrakcyjna jest pewnym uogólnieniem (generalizacją) innych
klas, lecz nie posiada swoich instancji, czyli obiektów.
Celem tworzenia klas abstrakcyjnych i interfejsów jest identyfikacja
wspólnych zachowań różnych klas, które są realizowane w różny od
wspólnych zachowań różnych klas, które są realizowane w różny od
siebie sposób.
Posiada ona deklaracje metod, ale nie definiuje ich implementacji.
Metody te implementowane są w klasach pochodnych 
specjalizacjach.
K. Bartecki, Inżynieria oprogramowania, V/70
Przykładowe klasy abstrakcyjne
K. Bartecki, Inżynieria oprogramowania, V/71
Przykład klasy abstrakcyjnej w kodzie języka C++
class Abstrakcyjna
{
public:
virtual void metodaCzystoWirtualna() = 0; // metoda czysto wirtualna
};
class Nieabstrakcyjna : public Abstrakcyjna // dziedziczenie
{
public:
void metodaCzystoWirtualna() // implementacja metody czysto wirtualnej
void metodaCzystoWirtualna() // implementacja metody czysto wirtualnej
{
// instrukcje metody
}
};
int main()
{
// Abstrakcyjna obiektX; // błąd, klasa jest abstrakcyjna
Nieabstrakcyjna obiektY; // poprawne
return 0;
}
K. Bartecki, Inżynieria oprogramowania, V/72
Przykład klasy abstrakcyjnej w kodzie języka Java
abstract class Figura {
abstract public double pole();
}
class Kolo extends Figura { // dziedziczenie
public double promien;
public Kolo( double p ) {
this.promien = p;
}
public double pole() { // implementacja metody czysto wirtualnej
return 3.14 * promien * promien;
}
}
public class Program {
public static void main( String[] args ) {
// Figura f = new Figura(); // niemożliwe: Figura jest klasą abstrakcyjną
Kolo k = new Kolo( 2 );
System.out.println( k.pole() );
}
}
K. Bartecki, Inżynieria oprogramowania, V/73
Interfejs
jest pojęciem bardzo podobnym do klasy abstrakcyjnej.
Zasadnicze różnice między interfejsem a klasą abstrakcyjną:
Klasa abstrakcyjna może posiadać implementacje niektórych operacji,
natomiast interfejs jest czysto abstrakcyjny i zawiera tylko deklaracje
swoich operacji.
Klasa dziedzicząca po klasie abstrakcyjnej może (ale nie musi)
Klasa dziedzicząca po klasie abstrakcyjnej może (ale nie musi)
implementować wszystkie operacje, natomiast w przypadku
dziedziczenia po interfejsie wszystkie  przejęte po nim operacje muszą
zostać zdefiniowane w klasie pochodnej.
O ile klasy potomne tej samej klasy abstrakcyjnej są pod względem
logicznym zwykle od siebie zależne, o tyle klasy dziedziczące po
interfejsie nie muszą być z sobą logicznie związane.
K. Bartecki, Inżynieria oprogramowania, V/74
Przykłady interfejsów
W języku C++ interfejs może być zdefiniowany jako klasa abstrakcyjna, zaś
w Javie, C#, Object Pascalu oraz PHP stosuje się w tym celu specjalną
deklarację ze słowem interface.
K. Bartecki, Inżynieria oprogramowania, V/75
Alternatywna ( lizakowa ) notacja interfejsu
K. Bartecki, Inżynieria oprogramowania, V/76
Przykład implementacji interfejsu w kodzie języka PHP
interface Sendable {
public function getTo();
}
class PhoneNumber implements Sendable {
public function getTo() { return '609123456' ; }
}
class Email implements Sendable {
public function getTo() { return '[e-mail]'; }
}
class Sender {
public function sendTo(Sendable $obj) { // operacje
}
}
$p = new PhoneNumber();
$e = new Email();
$s = new Sender();
$s->sendTo($p);
$s->sendTo($e);
K. Bartecki, Inżynieria oprogramowania, V/77
Przykładowy diagram klas
K. Bartecki, Inżynieria oprogramowania, V/78
Przykładowy diagram klas
K. Bartecki, Inżynieria oprogramowania, V/79
Diagram obiektów
prezentuje możliwą konfigurację obiektów w określonym momencie,
jest instancją diagramu klas, w której zamiast klas przedstawiono ich
instancje, czyli obiekty,
jest wizualizacją hipotetycznego stanu systemu podczas jego działania,
służy do tworzenia przykładów, pomagających zrozumieć diagram klas
oraz występujących w nim powiązań,
używa notacji zapożyczonej z diagramów klas, chociaż większość
z nich używa wyłącznie oznaczeń obiektów i asocjacji.
K. Bartecki, Inżynieria oprogramowania, V/80
K. Bartecki, Inżynieria oprogramowania, V/80
Diagram klas &
Klient
Zamówienie
składanie
1..1
- nr klienta : int
- nr zamówienia : int
0..*
- nazwisko : std::string
- Kwota zamówienia : float
& i przykładowy diagram obiektów
Z1:Zamówienie
Z1:Zamówienie
nr zamówienia = 1
Kwota zamówienia = 120.00
K1:Klient
nr klienta = 1
nazwisko = Kowalski
Z2:Zamówienie
nr zamówienia = 2
Kwota zamówienia = 175.00
K2:Klient
Z3:Zamówienie
nr klienta = 2 nr zamówienia = 3
nazwisko = Nowak Kwota zamówienia = 224.50
K. Bartecki, Inżynieria oprogramowania, V/81
Diagram klas &
& i przykładowy diagram obiektów
K. Bartecki, Inżynieria oprogramowania, V/82
Diagram klas &
& i przykładowy diagram obiektów
K. Bartecki, Inżynieria oprogramowania, V/83