Proj Sys Inter 2m

Modelowanie
klas i ich związków ±
diagram klas
Dr inĪ. Marek MIàOSZ
Plan
‡
‡
‡
‡
‡
Klasa ± notacja w UMLu
Związki ± typy, notacja
Diagram klas
Interfejs
ZáoĪone problemy modelowania klas i
ich związków
‡ Generowanie programowej realizacji
klas
© Marek MIàOSZ
2/60
ÄDojĞcie´ do klasy
Abstrakcja
Ksiazka
nr_inwentarzowy : int
autor : string
tytul : char
wydaw : Wydawnictwo
miasto : char
rokWydania : int = 2002
Formalizacja
KsiąĪka
© Marek MIàOSZ
zarejestruj()
wykresl_zRejestru()
sprawdzCzyJest()
sprawdzListe()
wypozyczKsiazke()
sprawdz_uKogo()
3/60
Jak ÄdojĞü´ do klas?
‡ Analiza lingwistyczna wymagaĔ uĪytkownika:
± Wyszukanie rzeczo wników (kandydaci na klasy
lub atrybuty)
± Wyszukanie czasowni ków (kandydaci na
zachowanie, metody)
± WyróĪnienie uĪytkowników ± aktorzy
‡ Wywiady z ekspertami
± Ramy formalne
± Scenariusze
± Sáowniki w dziedzinie problemowej
© Marek MIàOSZ
4/60
Analiza lingw istyczna przykáad
W bibliotece znajdują siĊ zbiory ksiąĪek
umieszczone na póákach regaáów oraz
zbiory czasopism, poáączonych w
roczniki. Studenci mogą wypo Īyczaü
ksiąĪki wypisuj ąc stosowny dokument
zwany rewersem. Studenci nie mog ą
wypo Īyczaü ksiąĪek znajdujących siĊ na
liĞcie ograniczeĔ. Czasopisma mogą byü
czytane przez studenta w czytelni.
© Marek MIàOSZ
5/60
Klasy w systemie
bibliotecznym
Biblioteka
Czytelnia
KsiąĪka
Student
Rewers
Czasopismo
Regaá
Póáka
© Marek MIàOSZ
6/60
KsiąĪka
Klasy ± notacja w UML
Atrybuty
Metody
‡ KlasĊ opisują cztery sekcje: nazwa,
atrybuty, metody, dokumentacj a (np.
zakres zobowi ązaĔ)
‡ Na diagramie ± róĪne przedstawi enie
KsiąĪka
Ksiazka
nr_inwentarzowy : int
autor : string
tytul : char
wydaw : Wydawnictwo
miasto : char
rokW ydania : int = 2002
Ksiazka
nr_inwentarzowy : int
autor : string
tytul : char
wydaw : Wydawnictwo
miasto : char
rokW ydania : int = 2002
zarejestruj()
wykresl_zRejestru()
sprawdzCzyJest()
sprawdzListe()
wypozyczKsiazke()
sprawdz_uKogo()
© Marek MIàOSZ
<<entity>>
Ksiazka
nr_inwentarzowy : int
<<datatype>> autor : string
tytul : char
wydaw : Wydawnictwo
miasto : char
rokW ydania : int = 2002
<<ewidencja>> zarejestruj() : bool
<<ewidencja>> wykresl_zRejestru() : bool
<<pytanie>> sprawdzCzyJest() : bool
<<pytanie>> sprawdzListe()
<<ruch>> wypozyczKsiazke(Id_studenta : char)
<<pytanie>> sprawdz_uKogo()
7/60
WáasnoĞci i typy klas
‡ Dziedziczenie - tworzy drzewo klas
(generalizacja-specjalizacja)
‡ Metaklasa (klasa abstrakcyj na) jest
Äwzorcem´ innych klas, poáączonych
operacją dziedziczenia
‡ Klasa konkretna ± stanowi wzorzec dla
obiektów
‡ Ekstensja klasy ± zbiór wszystkich
wystąpieĔ klasy (obiektów)
© Marek MIàOSZ
8/60
Metaklasa a klasa konkretna
OsobaPrawna
Nadklasa
Osob aFizy czna
XYZ : Firma
Firma
: OsobaPrawna
© Marek MIàOSZ
9/60
Atrybuty klasy
‡
‡
‡
‡
‡
Nazwa (identyfikator)
Typ (zaleĪny od jĊzyka)
Stereotyp
WartoĞü początkowa
DostĊpnoĞü (lista
eksportowa):
±
±
±
±
Publiczne (+)
Chronione (#)
Prywatne (-)
Implementacyjne
© Marek MIàOSZ
10/60
Typy atrybutów
Etapy:
Analiza
Projektowanie
‡ Proste ± predefiniowane w danym
jĊzyku lub dodefiniowane na etapi e
modelowania
‡ ZáoĪone ± definiowane jako klasy ze
stereotypem np.<<typedef>>,
<<struct>>, <<enum>> itp.
<<struct>>
Adres
kodPocztowy : char
miasto : char
ulica
numer
UML ± rozszerzalnoĞü systemu typów
© Marek MIàOSZ
11/60
Typy jako klasy - przykáady
W ektor
Punkt
RGB
x : float
y : float
z : float
xPozycja : int
yPozycja : int
kolor : RG B
kolorR : byte
kolorG : byte
kolorB : byte
ZáoĪone struktury
Typy wyliczeniowe
StanKsiazki
wy pozyczona
wRes tauracj i
wy slanaDoInnejBi bliot eki
znis zczona
skrad ziona
Stos
pop() : float
push(cos : float )
© Marek MIàOSZ
12/60
Rodzaje typów
‡ Proste, atomowe (character, integer, float, string,
boolean, bitmap, ...)
‡ Zapisy, rekordy (struct {nazwa:string;
waga:float;})
‡ Kolekcje:
± zbiory (sets) ± nieuporządkowane kolekcje unikalnych
danych: set of bitmap, set of struct {nazwa:string;
waga:float;}
± wielozbiory (bags) ± nieuporządkowane kolekcje
powtarzalnych danych : zbiory z powtórzeniami
± sekwencje (sequences): uporządkowane wielozbiory
± tablice (arrays)- sekwencje z dost Ċpem przez indeks:
array of integer, array[5..30] of set of bitmap
© Marek MIàOSZ
13/60
DostĊpnoĞü atrybutów
‡ Chronione (Protected)
‡ DostĊpnoĞü: klasa,
podklasa, klasa
zaprzyjaĨniona (w
zaleĪnoĞci od jĊzyka)
‡ Prywatne (Private)
‡ DostĊpnoĞü: klasa,
klasa zaprzyjaĨniona (w
zaleĪnoĞci od jĊzyka)
Uwaga na
ograniczenia
w dostĊpie przy
dziedziczeniu
© Marek MIàOSZ
14/60
Inne wáaĞciwoĞci atrybutów
Ksiazka
tytul : string
autorzy
rokWydania : int
czyWypozyczona : bool
ktoWypozyczyl : Student
/ wiekKsiazki : int
nazwaBiblioteki : string
Derived (obliczany na
podstawie innych atrybutów)
wypozycz(student : Student) : bool
zwroc(student : Student) : bool
obliczWiekKsiazki() : int
Static (identyczna wartoĞü
dla wszystkich obiektów
klasy)
© Marek MIàOSZ
15/60
Po co atrybut y obliczane?
‡ Brak czasu na ka Īdorazowe obliczanie,
kiedy są potrzebne (np. wyszukani e min
z duĪej liczby obiektów)
‡ Wybalansowanie pomiĊdzy szybkoĞcią
wykonania a zajĊtoĞcią pamiĊci
operacyjnej (oszczĊdnoĞü czasowa)
© Marek MIàOSZ
16/60
Jak dojĞü do atrybutów?
‡ WáaĞciwoĞci, statyczne charakter ystyki
zidentyfikowanych klas
‡ Dane, które zawierają, przechowują
klasy
‡ ÄRzeczowniki´, które nie zostaáy klasami
± Dane istotne dla SI
± Dane związane z obiektem
± Dane, które nie są zachowaniem
© Marek MIàOSZ
17/60
Specyfikacja i rodzaj metod
‡ Metoda moĪe mieü argumenty (oprócz
atrybutów obiektu, które są dostĊpne Äz
definicji´) oraz typ wyniku metody
‡ StopieĔ szczegóáowoĞci specyfikacji metod
zaleĪy od etapy projektowania
‡ Typy metod:
± Metoda abstrakcyjna ± metoda metaklasy
± Metoda obiektu ± operuje na atrybutach danego
obiektu
± Metoda klasy ± operuje na ekstensji klasy,
posiada dost Ċp do wszystkich obiekt ów danej
klasy
© Marek MIàOSZ
18/60
Metody - przykáady
Ksiazka
tytul : string
autorzy
rokWydania : int
czyWypozyczona : bool
ktoW ypozyczyl : Student
/ wiekKsiazki : int
nazwaBiblioteki : string
wypozycz(student : Student, dataWypoz : string) : bool
zwroc(student : Student, dataZwrotu : string) : bool
obliczWiekKsiazki() : int
obliczWiekKsiazki(rokWydania : int) : int
najstarszaKsiaĪka()
Metoda klasy
© Marek MIàOSZ
19/60
Metoda abstrakc yjna
OsobaPrawna
<<abstract>> obl icz PodatekMi esieczny() : float
OsobaFizyczna
<<stat ic>> oblicz PodatekM iesieczny()
Firma
<<static>> obliczPodatekMiesieczny()
Przesáanianie metod
© Marek MIàOSZ
20/60
Jak ÄdojĞü´ do metod?
‡ Metoda to operacj a realizowana przez
obiekt w ramach j ego zakresu
odpowiedzialnoĞci
‡ Abstrakcja czegoĞ, co moĪna zrobiü z
kaĪdym obiektem klasy
‡ Nazwy metod
± ÄCzasowniki´ z analizy dziedziny
± Wykorzystanie obiektu z perspektywy
uĪytkownika
© Marek MIàOSZ
21/60
Inna droga do metod
: Student
: Ksiazka
: Rewers
sprawdzCzyJest( )
nieMaKsiąĪki
wypozyczKsiazke(char)
wystawRewers
Diagramy sekwencji
Metoda ⇔ Komunikat
Ksiazka
sprawdzCzyJest() : bool
wypozyczKsiazka(tytul : char) : bool
© Marek MIàOSZ
22/60
Nazewnictwo - notacja
‡ Nazwa klasy ± rzeczownik z duĪej litery
‡ Atrybut ± rzeczownik z maáej litery
(pozostaáe z duĪej lub z ´_´ jako
separatorem)
‡ Metoda ± czasownik z maáej litery
(pozostaáe z duĪej lub z ´_´ jako
separatorem)
Ksi azka
nr_inwentarzowy : int
autor : string
tytul : char
wydaw : W ydawnictwo
miasto : char
rokWydania : int = 2002
© Marek MIàOSZ
zarejestruj()
wykresl_zRejestru()
sprawdzCzyJest()
sprawdzListe()
wypozyczKsiazke()
sprawdz_uKogo()
23/60
Związki
‡ Klasy są powiązane ze sobą róĪnymi
typami związków
‡ Typy związków:
± zaleĪnoĞü
± uogólnienie (generalizacja)
± powiązanie (asocjacja)
© Marek MIàOSZ
24/60
ZaleĪnoĞü
‡ ZaleĪnoĞü ± związek uĪycia; zmiany w
jednej klasie mogą mieü wpáyw na inną
± ale niekoniecznie na odwrót
KsiąĪka
Wydawc a
Tytuá : string
wydawcaKs : Wydawca
rokWyd : int
nazwaWyda : string
adres
‡ Grot skierowany w stronĊ klasy, od
której coĞ zaleĪy
© Marek MIàOSZ
25/60
Uogólnienie
‡ Związek generalizacji: klas ogólnaszczegóáowa
‡ Problem dziedziczenia atrybutów i
metod (dostĊpnoĞü-lista eksportowa,
przesáanianie)
‡ KorzeĔ ± klasa bez klas nadrzĊdnych
‡ LiĞü ± klas bez klas potomk ów
© Marek MIàOSZ
26/60
Powiązanie - asocjacja
‡ Związek struktural ny, powiązanie
logiczne obiektów z jednej klasy z
obiektami z innej (w szczególnoĞci z tej
samej klasy)
‡ Powiązania pomiĊdzy:
± obiektami tej samej klasy (jednoargumet owe)
± dwoma klasami (dwuargumentowe)
± wieloma klasami (wieloargument owe,
n-arne)
© Marek MIàOSZ
27/60
Jak ÄdojĞü´ do asocjacji?
‡ Czasowniki w dziedzinie problemowej (np.
wypoĪyczyá, zwróciá, jest egzemplarzem)
‡ Asocjacja áączy dwie klasy jeĞli:
± jedna klasa do drugiej wys yáa komunikat
± obiekt jednej klasy two rzy obiekt innej klasy
± obiekt jednej klasy posiada atrybut b Ċdący obiektem
(lub kolekcją) innej klasy
± obiekt jednej klasy otrzymuje komunikat z
argumentem-obiektem innej klasy
‡ Obiekt jednej klasy musi mieü dostĊp do danych
pewnego obiektu innej klasy ⇒ asocjacja
© Marek MIàOSZ
28/60
Powiązanie - wáaĞciwoĞci
‡
‡
‡
‡
‡
Nazwa
Role
LiczebnoĞü
Agregacja
Kompozycja
© Marek MIàOSZ
29/60
Nazwa asocjacji
(powiązania)
‡ Istota związku
‡ Jedna dla związku ± istotny kierunek
czytania związku
‡ Nie jest konieczna; szczeg ólnie gdy jest
oczywista
KsiąĪka
Student
wypoĪycza
Tytuá : string
wydawcaKs : Wydawca
rokWyd : int
© Marek MIàOSZ
nazwisko : string
imiĊ : string
specjalnosc : string
rok : char
30/60
Role klas w asocjacji
‡ Uszczegóáowienie roli klasy
‡ OpcjonalnoĞü
‡ Nazwa
Student
KsiąĪka
Tytuá : string
wydawcaKs : Wydawca
rokWyd : int
Firma
#przedmiot
#pracodawc a
wypoĪycza
pracuje dla
© Marek MIàOSZ
#klient
naz wisko : st ring
imiĊ : string
specjalnosc : st ring
rok : c har
#pracownik
Osoba
31/60
LiczebnoĞü (krotnoĞü)
asocjacji
‡ LiczebnoĞü obiektów jednej klasy
związana z obiektem innej klasy
posiada
Klient
Faktura
1
0..n
Oznaczenia:
0 0..1 0..n 1 1..n n 5..n
© Marek MIàOSZ
5..9
0..6
32/60
Asocjacja
jednoargumentow a
+szef
transak cja
0..1
Pracownik
+kupujący
1
Osoba
+podwáadny
1..n
1
© Marek MIàOSZ
+sprzedający
33/60
Role i liczebno Ğü
jest czáonkiem
Pracownik
0..n
0..n
Komitet
jest przewodniczącym
1
0..n
© Marek MIàOSZ
34/60
Asocjacje skierow ane
‡ Kierunek nawigacji (strzaáka)
‡ Nawigacja (przejĞcie) moĪliwe jest zgodnie
z kierunkiem
‡ Klient (bez grotu) mo Īe korzystaü z serwera
(klasa z grotem). Kl ient ma wskazani e na
serwera (deklaracja zmiennej klasy
serwera)
sk áada
Klient
1
Zamówienie
0..n
© Marek MIàOSZ
35/60
WidzialnoĞü w asocjacjach
skierowanych
Dostawca
Klient
‡ Globalne odwoáanie (referencja)
‡ Parametryczne (klasa Dostawca jest
parametrem metody Klienta lub jej wartoĞcią)
‡ Lokalne odwoáanie (obiekt Dostawcy jest
tworzony tymczasowo w metodzie Klienta)
‡ Poprzez pole (obiekt Dostawcy jest typem
pola Klienta)
© Marek MIàOSZ
36/60
Asocjacje
kwalifikowane
‡ Nazwa atrybutu (lub zbioru atrybutów)
realizujących związek
Firma
#pracodawca
pracuje dla
#pracownik
NIP_firmy
Faktura
numerFaktury
1
Osoba
Pozycja
1..n
© Marek MIàOSZ
37/60
Atrybuty asocjacji
(powiązaĔ)
Osoba
nazwisko
imiĊ
pesel
pracuje
1..n
0..1
Firma
regon
nazwa
Zatrudnienie
stanowisko
dataZatrudnienia
páacaPodstawowa
premiaPodstawowa
© Marek MIàOSZ
38/60
Asocjacja j ako obiekt
Osoba
nazwis ko
im iĊ
pesel
jest
1
0.. 1
Zatrudnienie
stanowisko
dataZatrudnienia
páacaPodstawowa
premiaPodstawowa
© Marek MIàOSZ
dotyczy
1..n
1
Firma
regon
nazwa
39/60
Asocjacje n-arne
‡ Związek (powiązanie) pomiĊdzy wiĊcej
niĪ dwoma klasami
Transakcja
Osoba::
Jan
Osoba::
Ela
sprzedaje
kupuje
data
kwota
przedmiotTransakcji
poĞredniczy
k upuje
sprzedaje
poĞredniczy
Osoba
Osoba::
Marek
nazwisko
imiĊ
pesel
© Marek MIàOSZ
40/60
Agregacja
‡ Szczególny przypadek asocj acji
(powiązania) odwzorowujący zaleĪnoĞü:
czĊĞü-caáoĞü (np. silnik-samochód)
‡ Reprezentacj a sytuacji, w której obiekty
jednej klasy (zwanej agregatem)
skáadają siĊ z obiektów innych klas
‡ Silnie związane z celem budowy
systemu: czy silnik zawsze jest
skáadową samochodu?
© Marek MIàOSZ
41/60
Agregacje - przykáady
Miasto
Wyáączna
Stowarzyszenie
1
n
0..n
Dzielnica
Wspóádzielona
Uczelnia
1..3
1..n
studiuje
10. .n
Osoba
n
n
Student
Ulica
© Marek MIàOSZ
42/60
Kompozycja
‡ Szczególny typ agregacji o silnej kontroli
wáasnoĞci i (co najwaĪniejsze) czasu Īycia
czĊĞci przez caáoĞü
‡ Nazewnictwo: agregat = kompozyt
czĊĞü = skáadnik
‡ Skáadniki kompozyt u nie mogą byü
wspóádzielone (tj. muszą byü związane z
jednym kompozytem)
‡ Skáadniki nie istnieją samoistnie i giną wraz z
kompozytem
© Marek MIàOSZ
43/60
Kompozycje - przykáady
Uczelnia
Okno
ma
1 1
ma
1
1..n
1
1
1
Nagáówek
0..2
Suwak
1
Ramka
3
Przyciski
Wydziaá
© Marek MIàOSZ
44/60
Diagram klas - przykáad
ma
Uczelnia
1
1..n
1..n
jest dziek anem
0..1
Wydziaá
1
oferuje
1
1..n
pracuje na
Kierunek
studiuje
Osoba
1 1..n
1
zawiera
Wykáadowca
prowadzi
n
1
uc zĊszcza na
Student
n
1..n
1..n
W ykáad
n
© Marek MIàOSZ
45/60
Diagram klas
‡ Statyczna struktura s ystemu
informatycznego
‡ MoĪe zawieraü tylko czĊĞü klas
systemu, np. kl asy z jednego pakietu
(podsystemu)
‡ MoĪliwa jest generacja kodu na
podstawie diagramu ± stopieĔ
szczegóáowoĞci kodu zaleĪy od stopnia
szczegóáowoĞci diagramu
© Marek MIàOSZ
46/60
Generowanie kodu ± C++
Faktura
numerFakt ury : int
dataW ystawienia : int
‡ Konieczny:
wy stawFakt ure()
stornujFakture()
± związek klasy z
jĊzykiem
± związek klasy z
komponentem
implementacyjnym
‡ Generacja kodu dla
komponentu l ub
klasy
/* plik nagáówkowy Faktura.h
class Faktura
{
public:
bool wystawFakture();
bool stornujFakture();
*/
int numerFaktury;
private:
/* ciaáo programu
Faktura.cpp
*/
int dataWystawienia;
#include "Faktura.h"
bool Faktura::wystawFakture()
};
{
}
bool Faktura::stornujFakture()
{
}
© Marek MIàOSZ
47/60
Generowanie kodu - Java
//Source file: E:\\Faktura.java
Fak tura
numerFaktury : Integer
dataWystawienia : Integer
public class Faktura
{
public Integer numerFaktury;
private Integer dataWystawienia;
public Faktura()
{
}
wystawFakture()
stornujFakture()
Faktura()
/**
* @return Boolean
* @roseuid 3E154DD903D8
*/
public Boolean wystawFakture()
{
return null;
}
/**
* @return Boolean
*/
public Boolean stornujFakture()
{
return null;
}
}
© Marek MIàOSZ
48/60
Realizacja powiązaĔ
(asocjacji) klas
JĊzyk C++
‡ Związki skierowane o krotnoĞci Ä1´ dla
agregacji lub kompozycji ± dodatkowy atrybut
typu klasy serwera
‡ Związki skierowane o krotnoĞci Ä1´ dla innych
związków ± dodatkowy atrybut typu
wskazującego na klasĊ serwera
‡ Związki skierowane o krotnoĞci Än´ (znanej) ±
tablice obiektów (wskazaĔ) klasy serwera
© Marek MIàOSZ
49/60
Powiązania skierow ane
Pozycja
lp : int
nazwaTowaru : string
iloscTowaru : string
cenaTowaru : float
Faktura
numerFaktury : int
dataWystawienia : int
wystawFakture() : bool
stornujFakture() : bool
+faktur
jest na
1
/* plik nagáówkowy Faktura.h
class Faktura
{
public:
bool wystawFakture();
bool stornujFakture();
1.. n
dodajPozycje()
poprawPozycje()
usunPozycje()
numerujPozycje()
/* plik nagáówkowy Pozycja.h
class Faktura;
class Pozycja
{
public:
dodajPozycje();
poprawPozycje();
usunPozycje();
*/
int numerFaktury;
*/
Faktura *faktur;
private:
int dataWystawienia;
};
© Marek MIàOSZ
private:
numerujPozycje();
int lp;
string nazwaTowaru;
string iloscTowaru;
float cenaTowaru;
};
50/60
Dziedziczenie w C++
Osoba
nazwisko : string
imie : string
pesel : string
Student
Wykladowca
nrAlbumu : double
class Osoba
{
protected:
string nazwisko;
dataZatrudnienia : double
#include "Osoba.h"
class Student : public Osoba
{
string imie;
double nrAlbumu;
string pesel;
};
};
© Marek MIàOSZ
51/60
Budowa modelu klas
‡ Wieloetapowa
‡ Pierwsze fazy projektu ± definiowanie
obiektów biznesowych, merytorycznych,
okreĞlających dziaáanie systemu
‡ Kolejne fazy ± definiowanie interfejsu,
obiektów ekranowych odpowiedzialnych za
komunikacje z uĪytkownikiem
‡ Klasy techniczne ± dostĊp do baz danych
(bezpoĞredni lub w architekturze klientserwer), komunikacja w sieci czy internecie
© Marek MIàOSZ
52/60
Ogólne reguáy
projektowania klas
‡ OdpowiedzialnoĞü klasy: 7±2 rzeczy
‡ Rozbicie odpowiedzialnoĞci ⇒ wiele
klas
‡ Podsystemy ± pakiety
‡ Dwa podejĞcia:
± DDD ± Data Driven Design (jakie dane?)
± RDD ± Responsibilit y Driven Design
(dziaáania?) ± metoda CRC
© Marek MIàOSZ
53/60
Metoda CRC
CRC = Class-Responsibilities-Collaborations
‡ Twórcy: K.Beck i W.Cunningham (1989)
‡ Nie jest czĊĞcią UML
‡ Cel: poszukiwanie klas
‡ Wspóápraca z przypadkami uĪycia
‡ Praca zespoáowa: burza mózgów,
analityce, eksperci , moderator
‡ Sprawdzanie poprawnoĞci ± odrywanie ról
© Marek MIàOSZ
54/60
CRC - narzĊdzie
Kartka papieru:
Nazwa klasy
OdpowiedzialnoĞü
- obowiązek
Odpow1
Odpow2
Odpow3
Wspólprac1
Wspólprac2
© Marek MIàOSZ
Wspóápracownicy
± inne klasy
55/60
CRC - szczegóáy
‡ OdpowiedzialnoĞü ± suma operacji
biznesowych obi ektów klasy
‡ Brak moĪliwoĞci wykonania operacji ±
brak w model u (nowa klasa lub
odpowiedzialnoĞü)
‡ Związek generalizacji-specjalizacji ±
zakres odpowi edzialnoĞci
© Marek MIàOSZ
56/60
CRC - przykáad
KsiąĪka
Zarządzanie danymi
o ksiąĪce
Sprawdzenie czy jest dostĊpna
Egzemplarz
Ksiazka
tytulKsiazki
autor1
autor2
wydawcaKsiazki
Egzemplarz
+wsk
ma
1
sprawdzCzyJest() : bool
rejestrujKsiazka()
0.. n
nrEwidencyjny
polka
wypozyczony
czyJestEgzemplarz()
© Marek MIàOSZ
57/60
CRC ± istota identyfikacji
klas
Samoch ód
‡ Konkretny
egzemplarz
wyprodukowany?
‡ Egzemplarz i jego
historia?
‡ Model?
‡ Pozycja w katalogu?
KsiąĪka
‡ Konkretny
egzemplarz?
‡ Wydanie?
‡ Tytuá wydawniczy?
‡ Partia dostarczana
do sklepu?
© Marek MIàOSZ
58/60
Klasy a rzeczywistoĞü
‡ Klasy są najbardziej stabilnym
elementem dzi edziny problemowej
‡ Funkcje, metody, dziaáania, procedury
siĊ zmieniają znacznie szybciej niĪ byty
‡ Oparcie SI o klasy umoĪliwia jego
stabilizacjĊ oraz wielokrotne (ponowne)
uĪycie fragmentów SI
© Marek MIàOSZ
59/60
Podsumowanie
‡ Diagram klas jest podstawowym
narzĊdziem modelowania aplikacji
‡ Istnieje moĪliwoĞü generowania
programu z uszczeg óáowionego
diagramu klas w poáączeniu z
diagramem komponent ów (podstawowy
element model u implementacyjnego)
© Marek MIàOSZ
60/60