Inżynieria oprogramowania
Projektowanie systemów informatycznych
Dr inż. Lucjan Miękina
upel.agh.edu.pl/wimir/login/
Katedra Robotyki i Mechatroniki
March 21, 2014
1/1
Inżynieria Oprogramowania
Diagramy klas i obiektów
Służą one do przedstawienia statycznego aspektu systemu  postaci jego elementów i
występujących między nimi powiązań.
Diagramy te przedstawiają klasy i interfejsy, będące podstawowymi składnikami
każdego systemu o obiektowej strukturze, a także różnorodne związki występujące
między tymi klasyfikatorami.
Diagramy te w związku z ich podstawowym znaczeniem dla modelowania SI, zostały
bogato oprzyrządowane: możliwe jest automatyczne generowanie kodu w wybranym
języku, odtwarzanie diagramu na podstawie istniejącego kodu (reverse engineering) i
inżynieria wahadłowa (round-trip engineering).
2/1
Inżynieria Oprogramowania
Symbol klasy
Symbol klasy jest prostokątem, wewnątrz którego wyróżnia się części specyfikujące
kolejno nazwę klasy, jej atrybuty i operacje, a czasem również zobowiązania. Zarówno
atrybuty jak i operacje posiadają zdefiniowany dostęp: prywatny, chroniony lub
publiczny, oznaczane odpowiednio symbolami -, # i +.
Lewa część rysunku poniżej przedstawia klasę pierwotną Punkt2D, posiadającą 3
atrybuty i 4 operacje. Cechy klasy są zapisywane w postaci atrybutów klasy lub
asocjacji z innymi klasami. Atrybuty reprezentują wartości proste lub niewielkie
obiekty, asocjacje  obiekty złożone.
Format specyfikacji atrybutu:
widocznosc nazwa : typ [krotnosc] {ograniczenia} = wartosc domyslna
Format specyfikacji operacji:
widocznosc nazwa(parametry) : typ
3/1
Inżynieria Oprogramowania
Symbol tabeli
Przy użyciu stereotypu table uzyskano definicję tabeli bazy danych Tabela. W części
zawierającej atrybuty, opatrzonej stereotypem column zostały zdefiniowane kolumny
tabeli: imie, imie2, nazwisko i pesel. Znak  * przed nazwą atrybutu oznacza
wymaganie, by wartość atrybutu nie była pusta, PK jest zaś oznaczeniem klucza
głównego (primary key). Metoda PK_Tabela jest implementacją operacji na kluczu
głównym.
Ten przykład ukazuje elastyczność i rozszerzalność języka UML, która wynika z
mechanizmu stereotypów, którymi można opatrywać standardowe konstrukcje i w ten
sposób zmieniać ich znaczenie.
4/1
Inżynieria Oprogramowania
Interfejsy
Interfejs jest zestawem operacji, które wyznaczają usługi oferowane przez klasę lub
komponent. Deklaracja interfejsu jest to specyfikacja własności związanych z
operacją/ami (choć interfejs może posiadać również atrybuty), która ma znaczenie dla
klas implementujących go i klas korzystających z niego. Ma to zastosowanie przy
specyfikowaniu współpracy obiektów między sobą. Wszystkie klasy implementujące i
wykorzystujące dany interfejs muszą to uczynić zgodnie z jego deklaracją; jest to
rodzaj kontraktu, który musi być dochowany, by komunikacja mogła być realizowana.
Podstawowy symbol interfejsu jest podobny do symbolu klasy, dodatkowo opatrzonej
stereotypem interface. Alternatywnie interfejs może być przedstawiony symbolem
okręgu, wtedy podaje się tylko jego nazwę, a symbol realizacji jest pozbawiony
strzałek.
Przykład przedstawia deklarację interfejsu IKomunikacja, który deklaruje 2 publiczne
metody (odbierz i wyslij). Interfejs jest w relacji typu realizacja z klasą Urzadzenie, co
oznacza że ta klasa implementuje interfejs, czyli zawiera kod operacji odbierz i wyslij.
5/1
Inżynieria Oprogramowania
Zależności
Zależność jest to związek wynikający z użycia jednego elementu modelu przez inny.
Jeśli dokona się zmian w definicji elementu, to będą one miały wpływ na zależny
element. Na diagramie przedstawia się zależność linią przerywaną z grotem
skierowanym na element, od którego coś zależy. Aby bardziej szczegółowo określić
zależność, można opatrzyć ją stereotypem.
A
ącznie jest 17 stereotypów, z czego główna część (osiem) dotyczy zależności w
ramach diagramów klas, dwa dotyczą zależności w ramach diagramów pakietów
(access i import), dwa dotyczą zależności w ramach diagramów przypadków użycia
(include i extend), trzy dotyczą zależności w ramach diagramów interakcji (become,
call i copy), jeden dotyczy zależności w ramach diagramów maszyny stanowej (send).
Przykład przedstawia zależność między klasą Zalezna i klasą Punkt2D, która wynika z
użycia nazwy klasy Punkt2D jako typu argumentu operacji odbierz.
6/1
Inżynieria Oprogramowania
Powiązania
Powiązania, zwane też asocjacjami, są głównym rodzajem związków między klasami.
Opisują one połączenia między instancjami klas. Powiązania mogą być binarne
(między dwoma klasami) i n-arne (wielostronne, wiążące większą ilość klas).
Implementacja powiązań binarnych ma postać atrybutu klasy z
ródłowej, będącego
instancją klasy z nią powiązanej.
Powiązania można opisywać podając nazwę, role klas uczestniczących, widoczność,
nawigację, liczebność i sposób agregacji. Widoczność określa, czy można uzyskać
dostęp do obiektów wzdłuż powiązania ze strony obiektów zewnętrznych (nie
biorących w nim udziału). Jeśli nie określono nawigacji, należy przyjąć, że jest ona
dwukierunkowa: można przejść od obiektów jednej klasy do obiektów drugiej klasy i na
odwrót.
7/1
Inżynieria Oprogramowania
Agregacje
Agregacja może mieć dwie odmiany: zwykłą i całkowitą (zwaną też kompozycją):
Agregacja zwykła służy tylko do pojęciowego odróżnienia całości od części. Na
diagramach rysuje się ją przez dodanie do zwykłego powiązania pustego rombu
po stronie całości.
Kompozycja cechuje się wyłącznym posiadaniem części przez całość, co oznacza
również zawieranie się czasu istnienia części w czasie istnienia całości (części o
nieustalonej liczebności mogą powstawać po utworzeniu całości, ale są niszczone
najpóz
niej tuż przed zniszczeniem całości). Na diagramach rysuje się kompozycję
przez dodanie do zwykłego powiązania wypełnionego rombu po stronie całości.
Przykład przedstawia zastosowania agregacji obu rodzajów. Obiekt klasy
SystemPlików jest powiązany z obiektem typu Plik w taki sposób, że SystemPlików
posiada nieograniczoną ilość obiektów Plik, przechowywanych w prywatnym atrybucie
pliki. Dodatkowo zdefiniowano drugie powiązanie między tymi klasami, które
reprezentuje dowiązania do plików (link).
8/1
Inżynieria Oprogramowania
Klasy powiązania
W celu modelowania złożonych powiązań, czyli takich które mają specyficzne
własności, stosuje się klasy powiązania (inaczej asocjacyjne). Zawierają one te
atrybuty i operacje charakterystyczne dla powiązania, których nie można opisać
standardowymi, omówionymi dotychczas metodami. Na diagramie przedstawia się
klasę powiązania w postaci symbolu klasy, który jest połączony z powiązaniem linią
przerywaną.
Przykład przedstawia klasę Kontrakt, która definiuje własności powiązania między
klasami Przedmiot i Osoba. Powiązanie to opisuje zależności między przedmiotami
wykładanymi na uniwersytecie i osobami prowadzącymi zajęcia z tych przedmiotów.
Ponieważ sama deklaracja powiązania, ze zdefiniowanymi rolami Przedmiot i
Prowadzący, nie wystarcza do pełnego opisu powiązania, zastosowano klasę
asocjacyjną Kontrakt, która zawiera atrybuty określające kategorię zajęć, kierunek
studiów, semestr i ilość godzin do zrealizowania.
9/1
Inżynieria Oprogramowania
Uogólnienia
Uogólnienie, inaczej generalizacja jest to związek między elementem ogólnym
(zwanym nadklasą) a pewnym jego rodzajem (zwanym podklasą). Uogólnienie polega
na tym, że podklasa dziedziczy atrybuty i operacje po nadklasie. Podklasa może mieć
własne atrybuty i operacje, a ponadto może mieć przedefiniowane operacje nadklasy.
Podklasa może wystąpić wszędzie tam, gdzie jest spodziewana nadklasa, czyli może
zastąpić nadklasę.
Na rysunku a) przedstawiono przykład użycia uogólnienia, w którym biorą udział klasy
Punkt2D (reprezentuje punkt w przestrzeni dwuwymiarowej) i Punkt3D (reprezentuje
punkt w przestrzeni trójwymiarowej). Alternatywnie można przedstawić uogólnienie
przy użyciu dodatkowego napisu umieszczonego wewnątrz sekcji nazwy podklasy, jak
na rysunku b). Napis ten zawiera nazwę nadklasy napisaną pismem pochyłym.
10/1
Inżynieria Oprogramowania
Klasy szablonowe
Szablon klasy określa, z jakimi innymi klasami (ale nie obiektami!) lub parametrami
określonego typu może współpracować dana klasa. Te klasy lub parametry są
przekazywane jako parametry szablonu. W specyfikacji podaje się, czy chodzi o klasę
czy parametr określonego typu.
Poniższy przykład pokazuje klasę Wektor z dwoma parametrami szablonu:
T  określa klasę elementów wektora
cnt jest typu int i ma wartość domyślną równą 10 (nie uwidocznioną). Określa
ilość elementów wektora.
11/1
Inżynieria Oprogramowania
Klasy zagnieżdżone
W pewnych sytuacjach element diagramu, na przykład klasa, powinien mieć
ograniczoną widoczność. Typowym przykładem jest pomocnicza klasa, która jest
używana tylko wewnątrz innej klasy, nie ma więc powodu deklarować jej publicznie.
Należy wtedy zastosować symbol zagnieżdżenia, który jest zlokalizowany w pobliżu
klasy zewnętrznej.
Przykład przedstawia klasy Zewnętrzna i Wewnętrzna związane opisaną relacją.
Efektem tego w implementacji będzie umieszczenie kodu klasy Wewnętrzna wewnątrz
klasy Zewnętrzna.
12/1
Inżynieria Oprogramowania
Diagramy obiektów
Diagramy obiektów mogą być uważane za specjalny rodzaj diagramu klas. Diagramy
obiektów używają podzbioru elementów dostępnych w diagramach klas w celu
ukazania związków pomiędzy instancjami klas w pewnych chwilach czasu. Są one
pomocne w analizie i zrozumieniu diagramów klas, przez ukazanie krotności obiektów i
ich współpracy.
Klasy i obiekty
Poniższy diagram ukazuje różnice między symbolem klasy i obiektu. Symbol klasy
składa się zwykle z trzech sekcji - nazwy, atrybutów i operacji, podczas gdy symbol
obiektu nie zawiera sekcji. Także sposób ukazania jest inny - nazwa obiektu jest
podkreślona i opcjonalnie, po dwukropku podaje się nazwę klasy.
13/1
Inżynieria Oprogramowania
Diagramy obiektów
Stan obiektu
Klasa może zawierać pewną ilość atrybutów i metod. Zwykle nie są one ukazane w
symbolu obiektu. Można jednak zdefiniować stan obiektu (object s run time state),
złożony z wartości atrybutów, jakie wystąpią w konkretnej instancji i w danej chwili.
14/1