Diagramy klas

Halina Tańska

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

Diagram klas

Kluczowymi elementami są

:

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

Dodatkowo diagram może zwierać

:

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

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.

Diagram klas

Klasa jest

opisem zbioru obiektów

,

które mają takie same:

•atrybuty
•operacje
•związki
•znaczenia

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.

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.

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.

dokonanie
rejestracji

zarejestrowanie

Właściciel

własność

wniesienie
o
rejestrację

Rejestrator

wykonanie
czynności
urzędowej

Rejestracja

Pojazd

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.

Diagram klas

Klasa w notacji
UML

Nazwa

Atrybuty

Operacje

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.

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.

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

i

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;

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

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

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.

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

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

Klasa

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

Operacj
e

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

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

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.

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.

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.

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.

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.

Klasa

Odpowiedzialność klasy

class Logical View

Kurs

Wykład

Student

Pracownik

Osoba

Profesor

+poprzedni
0..1

+następny
*

1..*

+zapisany na

1..*

*

+prowadzący

1

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

Klasa

Widoczność Public

+

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

Klasa

Widoczność Protected

#

Atrybut lub operacja jest widoczna dla
potomków klasy.

Klasa

Widoczność Private

-

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

Klasa

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

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

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.

Interfejs

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

Interfejsy

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

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.

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:

Interfejs dostarczany

Nazwa interfejsu:
• prosta

np.: IPisownia

• ścieżkowa

np.: UsługiSieciowe::IRouter

Interfejs dostarczany

Interfejs jest

definicją usług

oferowanych

przez klasę lub

komponent.

Interfejs wymagany

Interfejs wymagany są to

usługi,

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

.

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.

Interfejs

Interfejs wymagany i dostarczany

OCENY

protokółEgzamina
cyjny

IOceny

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

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

Asocjacje – cechy

• nazwa

• rola

• nawigacja

Kierownik

projektu

Projekt

zarządza

Kierownik

projektu

Projekt

szef

zarządza

zadanie

Kierownik

projektu

Projekt

szef

zarządza

zadanie

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

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

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

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

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

Związki

Uogólnienie

Dziekan

Wykładow
ca

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

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.

Związki

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

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

Związki

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

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

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?

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

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

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.

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”

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.

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

.

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.

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.

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

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.

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

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

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ą

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}

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

Diagramy klas

Diagramy klas

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.