E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 1

Projektowanie systemów

informacyjnych

Ewa Stemposz, Kazimierz Subieta

Instytut Podstaw Informatyki PAN,
Warszawa

Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa

Wykład 6

Model obiektowy (3)

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 2

Zagadnienia

Faza analizy
Faza projektowania
Perspektywy: pojęciowa, projektowa i implementacyjna
Proces tworzenia modelu obiektowego
Identyfikacja obiektów i klas
DDD a RDD
Metoda CRC
Identyfikacja klas poprzez identyfikację rzeczowników
Identyfikacja związków między klasami

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 3

Faza analizy

 ustalenie kontekstu projektu (przyszłych użytkowników),
 ustalenie wymagań użytkowników,
 rozpoznawanie, wyjaśnianie, modelowanie, specyfikowanie i
dokumentowanie rzeczywistości będącej przedmiotem projektu
(dziedziny problemowej/przedmiotowej).

W zasadzie analiza nie powinna stawiać nacisku na zmianę
rzeczywistości poprzez wprowadzenie tam nowych elementów np.
w postaci systemu komputerowego. Jej celem jest rozpoznanie
tych wszystkich aspektów dziedziny problemowej, które mogłyby
być poddane procesowi informatyzacji.

Czynności wykonywane w fazie analizy to:

Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja

Faza strategiczna

Analiza

Instalacja

Dokumentacja

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 4

Faza projektowania

Celem fazy projektowania jest opracowanie szczegółowego planu
implementacji systemu.

W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa
środowisko implementacji. Projektanci muszą posiadać dobrą
znajomość języków, bibliotek i narzędzi stosowanych w trakcie
implementacji.

Dąży się, by struktura modelu logicznego zachowywała strukturę
modelu stworzonego w poprzedniej fazie (analizie) – podejście
bezszwowe (seamless). Niewielkie zmiany w dziedzinie problemowej
powinny implikować niewielkie zmiany w modelu logicznym.

Może to być realizowane, np. poprzez wykorzystanie podejścia
obiektowego.

Określenie wymagań

Projektowanie

Implementacja Testowanie Konserwacja

Faza strategiczna

Analiza

Instalacja

Dokumentacja

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 5

Zadania fazy projektowania

 Uszczegółowienie wyników analizy. Model logiczny musi być
wystarczająco szczegółowy, aby mógł stanowić podstawę dla
implementacji. Stopień szczegółowości zależy od poziomu
zaawansowania programistów.

 Dostosowanie do ograniczeń i możliwości środowiska
implementacji.

 Projektowanie tych składowych systemu, które nie są
związane z dziedziną problemową.

 Optymalizacja systemu.

 Określenie fizycznej struktury systemu (projekt architektury
systemu).

Zadania stojące przed wykonawcami w fazie projektowania:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 6

Uszczegóławianie wyników analizy (1)

Uszczegóławianie wyników analizy: poprzez podanie reguł
odwzorowania notacji dla danych (notacji stosowanej w modelu
pojęciowym – wyniku fazy analizy) w struktury tego języka
programowania, który będzie wykorzystany do implementacji
systemu.

Dane osobowe
Imię
Nazwisko
Adres

Adres
Ulica
Numer domu
Numer mieszkania
Miasto
Kod

typedef struct {

char Ulica[30];

int NumerDomu;
int NumerMieszkania;
char Miasto[30];
char Kod[5];
} TypAdres;

typedef struct {

char Imię[30];
char Nazwisko[30];
TypAdres Adres;
} TypDaneOsobowe;

Dane z analizy

Realizacja w C/C++

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 7

Uszczegóławianie wyników analizy (2)

Uszczegóławianie
metod

:

 Podanie pełnych sygnatur metod (wyspecyfikowanie typów
argumentów oraz wartości zwracanej dla każdej metody).

 Zastąpienie niektórych prostych metod publicznym dostępem do
atrybutów, np.
metod: pobierzNazwisko, ustawNazwisko, etc.

 Zastąpienie niektórych atrybutów redundantnych (pochodnych)
wyłącznie przez metody (usunięcie atrybutu z klasy), np.

/wiek --> policzWiek() // wiek = bieżącaData
- dataUrodzenia;
/kwotaDochodu --> policzDochód() // dochód = przychód -
koszty;

Decyzję o usunięciu atrybutu pochodnego z klasy podejmujemy w
oparciu

o

koszt

liczenia,

częstość

zmian

i

częstość

wykorzystywania, np. możemy zdecydować się na przechowywanie
atrybutu o wysokim koszcie liczenia, rzadko zmienianej wartości i
często wykorzystywanym.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 8

Uszczegóławianie wyników analizy (3)

Określenie sposobów implementacji
asocjacji:

Asocjacje można zaimplementować na wiele sposobów, z reguły poprzez
wprowadzenie dodatkowych atrybutów. Mogą one być następujące:

 obiekt (lub kolekcja obiektów) powiązanej klasy,

 wskaźniki (referencje) do obiektów powiązanej klasy,

 identyfikatory obiektów powiązanej klasy,

 klucze kandydujące obiektów powiązanej klasy.

W zależności od przyjętego sposobu oraz od liczności związków (1:1,
1:wiele, wiele:wiele) możliwe są bardzo różne deklaracje w przyjętym
języku programowania.

TypSłowoKluczowe SłowaKluczowe[100];
list<TypSłowoKluczowe*> SłowaKluczowe;
char *WskaźnikiSłówKluczowych[100];

Tablica obiektów:
Lista wskaźników:
Tablica wskaźników:

Symbol graficzny

Słowo kluczowe

*

*

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 9

Raczej projektowanie niż analiza (1)

Asocjacje skierowane: oprócz oznaczenia asocjacji zaznacza się
też kierunek przesyłania komunikatów (nawigację). Np. w systemie
Systemie Informacji Graficznej nawigacja jest możliwa jedynie od
obiektów klasy “Symbol graficzny” do obiektów “Słowo kluczowe”.
Jest to jeden ze scenariuszy; w innym może być inaczej.

Symbol graficzny

Słowo kluczowe

 Oznaczenia dostępności dla atrybutów, metod i klas:

(+) publiczny – dla wszystkich
(#) zabezpieczony (protected) – dostęp dla obiektów danej klasy oraz jej specjalizacji
(-) prywatny – dostęp tylko dla obiektów danej klasy

Symbol graficzny
# Nazwa
# Rysuj
+ Wyświetl
+ Wyświetl_opis

Słowo kluczowe
+ Nazwa
- Stan
+ Pobierz_stan
+ Zmień_stan

*

*

*

*

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 10

Raczej projektowanie niż analiza (2)

Wzorce klas (szablony)

Metaklasy, tj. klasy zawierające atrybuty i metody
dotyczące klasy jako całości, a nie pojedynczych obiektów,
np. realizujące atrybuty i metody klasowe innej klasy
(własności statyczne).

Wolne funkcje – funkcje nie będące metodami żadnej z
klas.

Stereotypy (np.:

«

persistent

»

,

«

constructor

»

,

«

query

»

) ?

wartości etykietowane

?

Szczegółowe specyfikacje atrybutów i metod

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 11

Składowe nie związane z dziedziną

problemową

Model logiczny skonstruowany drogą uszczegółowienia modelu
pojęciowego (wyniku fazy analizy) opisuje składowe systemu
odpowiedzialne za realizację podstawowych zadań systemu,
związanych z daną dziedziną problemową.

Gotowe oprogramowanie musi także zawierać składowe nie
związane z dziedziną problemową:

 składową interfejsu
użytkownika,

 składową zarządzania
danymi
(przechowywanie trwałych
danych),

 składową zarządzania
pamięcią
operacyjną,

 składową zarządzania
zadaniami
(podział czasu procesora).

Składowa

dziedziny

problemowej

Składowa

dziedziny

problemowej

Składowa

zarządzania

danymi

Składowa

zarządzania

danymi

Składowa

zarządzania

zadaniami

Składowa

zarządzania

zadaniami

Składowa

interfejsu

użytkownika

Składowa

interfejsu

użytkownika

Składowa

zarządzania

pamięcią

Składowa

zarządzania

pamięcią

(do 90% nakładów;
obecnie poprzez GUI)

(kompilator,
system operac.)

(kompilator,
system operac.)

(SZBD)

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 12

Perspektywy (1)

 Perspektywa pojęciowa (koncepcyjna) – model pojęciowy powinien
w zasadzie przedstawiać jedynie te pojęcia, które funkcjonują w
dziedzinie problemu (w analizowanej rzeczywistości), np. mówimy o
operacjach wykonywanych na bytach, a nie o implementujących je
metodach, atrybuty to cechy opisujące byty, z kolei asocjacje opisują
związki semantyczne występujące pomiędzy bytami. Model pojęciowy w
ogóle (lub w bardzo niewielkim stopniu) powinien interesować się
implementującym go softwarem.

Można wyróżnić trzy perspektywy, które powinny być brane pod
uwagę w trakcie w konstruowania dowolnego modelu (diagramu):

 Perspektywa projektowa (logiczna) – tu uwzględniamy już
software, ale interfejs a nie implementację, czyli myślimy raczej o
typach niż o klasach. Typ reprezentuje interfejs, który może mieć
wiele implementacji, np. uzależnionych od środowiska programowania
(przyjętej platformy), żądanych charakterystyk wydajnościowych czy
nawet sprzedawcy. Chociaż podejście obiektowe kładzie wielki nacisk
na rozróżnienie między interfejsem a implementacją, w praktyce w
wielu językach obiektowych nie oddziela się wyraźnie interfejsu od
implementacji, co się zresztą zmienia na lepsze (przykład: Java,
Corba).

 Perspektywa implementacyjna

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 13

Perspektywy (2)

Zrozumienie perspektywy, która była brana pod uwagę w trakcie
konstruowania danego modelu, jest ważnym czynnikiem mającym
wpływ

na

prawidłowe

interpretowanie

modelu.

Prawidłowa

interpretacja, dobre zrozumienie jest warunkiem koniecznym
prawidłowego wykorzystania później. Niestety nie dość, że granice
między perspektywami nie są wyraźnie zakreślone, to jeszcze wielu
analityków i projektantów w ogóle lekceważy ten problem i konstruuje
swoje modele od razu z perspektywy implementacyjnej, podczas gdy te
inne mogłyby w danym momencie być znacznie bardziej użyteczne.
Nadmiar informacji może też stanowić stanowić pewne
ograniczenie.

Zalecenia:

 jeśli konstruujesz model, konstruuj go z jednej, wyraźnie określonej perspektywy,

 perspektywę tę możesz opisać wykorzystując stereotypy lub wartości etykietowane,

 kiedy przeglądasz model musisz być świadom z jakiej perspektywy został skonstruowany,
aby go poprawnie zinterpretować.

Modele, tak jak i całość projektu, zawsze powstają (a
przynajmniej powinny powstawać) w sposób iteracyjny i
przyrostowy.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 14

Tworzenie modelu obiektowego (dwie

drogi)

Zadania:

 Identyfikacja obiektów i klas
 Identyfikacja związków pomiędzy klasami (generalizacji-specjalizacji, asocjacji,

zależności, realizacji)
 Identyfikacja i definiowanie atrybutów
 Identyfikacja i definiowanie metod i komunikatów

Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania
nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego
problemu.

Inny schemat realizacji procesu budowy modelu obiektowego polega
na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w
późniejszej fazie następuje identyfikacja klas, związków, atrybutów i
metod. Rozpoznaniu funkcji systemu służy model przypadków użycia
oraz analiza dynamiczna.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 15

Identyfikacja klas

Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o
podobnych

własnościach,

wyróżnialnych

w

analizowanej

rzeczywistości), to kluczowa umiejętność w obiektowym podejściu
do procesu konstruowania oprogramowania.

Klasy są najbardziej stabilnym elementem dziedziny
problemowej. Dobry system oparty jest tak dalece, jak tylko
jest to możliwe, na klasach reprezentujących grupy bytów
wyróżnialnych w dziedzinie problemowej, a nie na
funkcjonalności potrzebnej dziś i to dla specyficznego być
może zastosowania. Oprogramowanie wykorzystujące klasy
powstałe w wyniku analizy dziedzinowej jest znacznie
bardziej odporne na zmiany wymagań niż oprogramowanie
oparte o jednostki funkcjonalne.

Oparcie

oprogramowania

o

wykorzystanie

klas

ma

fundamentalne znaczenie dla technologii ponownego użycia.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 16

Typowe klasy

Typowe klasy:

 przedmioty namacalne (samochód, czujnik)
 grupy przedmiotów namacalnych (kartoteka, samochód jako
zestaw części)
 role pełnione przez osoby (pracownik, wykładowca, student)
 zdarzenia, o których ma być przechowywana informacja
(lądowanie samolotu, wysłanie zamówienia, dostawa)
 interakcje pomiędzy osobami i/lub systemami, o których
mają być przechowywane informacje (pożyczka, spotkanie,
sesja)
 lokalizacje – miejsce przeznaczone dla ludzi lub
przedmiotów
 organizacje (firma, wydział, związek)
 wydarzenia (posiedzenie sejmu, demonstracja uliczna)
 koncepcje i pojęcia (zadanie, miara jakości)
 dokumenty (faktura, prawo jazdy)

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 17

Obiekty, zbiory obiektów, metadane

W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z
jakiego rodzaju bytem mamy do czynienia.

 egzemplarz samochodu wyprodukowany przez pewną
fabrykę

 historię stanów pewnego konkretnego samochodu

 model samochodu produkowany przez fabrykę

 pozycję w katalogu samochodów opisujący własności
modelu

 konkretny egzemplarz gazety kupiony przez
czytelnika

 konkretne wydanie gazety (niezależne od ilości
egzemplarzy)

 partię egzemplarzy danej gazety dostarczaną
codziennie do kiosku

 tytuł i wydawnictwo, niezależne od egzemplarzy i
wydań

 czy mamy do czynienia z konkretnym bytem w danej
chwili czasowej?

 czy mamy do czynienia z konkretnym bytem w pewnym
odcinku czasu?

 czy mamy do czynienia z pewnym zbiorem konkretnych
bytów?

 czy mamy do czynienia z opisem bytu (dokument,
metadane)?

Podobnie z klasą Gazeta. Może chodzić o:

Np. klasa Samochód. Może chodzić o:

Należy zwrócić uwagę na następujące aspekty:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 18

Identyfikacja klas: RDD a DDD

Eksperci

od

obiektowego

podejścia

do

procesu

tworzenia

oprogramowania dzielą się na dwa obozy w zależności od
proponowanego przez nich sposobu identyfikacji klas:

 w oparciu o odpowiedzialności klas (RDD – Responsibility Driven Design),

 w oparciu o dane (DDD – Data Driven Design).

RDD – tutaj rozpoznaje się wszystkie odpowiedzialności systemu (w
oparciu o potrzeby przyszłych użytkowników) i bazując na nich
wyróżnia się klasy; przykładem jest tu metoda CRC wykorzystywana
w kilku metodykach.

Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane,
wykorzystujące każdą dostępną metodę.

Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy.

DDD – polega na zidentyfikowaniu wszystkich danych w systemie i
podziale

ich

na

klasy

bez

specjalnego

rozważania

ich

odpowiedzialności; przykładem tej techniki jest identyfikacja
rzeczowników i fraz rzeczownikowych w tekście wymagań.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 19

Metoda CRC (1)

Metoda CRC (Class, Responsibilities, Collaborations) została
zaprezentowana przez K. Beck’a i W. Cunningham’a w 1989 r. w celu
ułatwienia

programistom

“nie-obiektowym”

naukę

“myślenia

obiektowego”. Okazała się być przydatna na wczesnych etapach
rozwoju systemu do identyfikacji klas. Metoda CRC nie jest częścią
UML.

Na małej kartce papieru notuje się następujące elementy:

 u góry kartki – nazwę klasy,

 po lewej stronie – odpowiedzialności (responsibilities), czyli
obowiązki danej klasy,

 po prawej stronie – współpracowników (collaborators), czyli klasy,
które pomagają danej klasie w wypełnianiu jej obowiązków.

Odpowiedzialności danej klasy opisywane są na wysokim poziomie
abstrakcji – jako podstawa (główny powód, cel) zaistnienia danej klasy.
Są powiązane z operacjami, które można wykonywać na obiektach tej
klasy, ale są wyrażone w bardziej ogólny sposób. Np. akceptowalna jest
odpowiedzialność, taka jak “zarządzanie danymi dotyczącymi książki”,
co implikuje operacje, które czytają i zapisują dane. Klasa nie powinna
mieć więcej niż trzy, cztery odpowiedzialności (wiele klas ma tylko
jedną lub dwie). Jeśli klasa ma zbyt dużo odpowiedzialności (niska
kohezja), należy zastanowić się czy zostały one dostatecznie zwięźle
określone lub czy nie rozdzielić odpowiedzialności i mieć więcej klas.
Zbyt wielu współpracowników sugeruje zbyt silne skojarzenie klas.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 20

Metoda CRC (2)

 CRC wykorzystuje się wspólnie z przypadkami użycia – postępując w
zgodzie ze scenariuszem identyfikuje klasy, których odpowiedzialności
włączają

potrzebną

operację

i

znajduje

ewentualnych

współpracowników, zaangażowanych w realizację danego przypadku
użycia. Upraszczając – odpowiedzialności każdej klasy mogą być
postrzegane jako suma operacji, które można wykonywać na obiektach
tej klasy.

 Kiedy brakuje klasy, która mogła by wykonać potrzebną operację,
oznacza to błędy lub braki w modelu. Być może trzeba dodać nową klasę
lub zmienić odpowiedzialności lub współpracowników klasy już
istniejącej (być może jedno i drugie).
 Związek generalizacji-specjalizacji jest tu wyjaśniany w kategoriach
współdzielenia

odpowiedzialności

i

współpracowników.

Klasa

specjalizowana ma te własności odpowiednio większe.

 Sytuacja ta może też być postrzegana w drugą stronę – jeśli dwie klasy
mają nakładające się odpowiedzialności i współpracowników, to może to
być sugestia dla wydzielenia dla nich nadklasy.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 21

CRC- identyfikacja klas; przykład

Osoba

Odpowiedzialności

Współpracownicy

 zarządzanie danymi dotyczącymi osoby

 wypełnianie ograniczeń narzuconych na
liczbę wypożyczanych pozycji

książka
czasopismo

Książka

Odpowiedzialności

Współpracownicy

 zarządzanie danymi dotyczącymi książki

 sprawdzanie, czy są wolne egzemplarze do
wypożyczenia

egzemplarz

Biblioteka: Biblioteka zawiera książki i czasopisma. Może być kilka
egzemplarzy tej samej książki. Tylko personel może wypożyczać
czasopisma. Członek biblioteki może mieć jednocześnie wypożyczonych
sześć pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich
wypożyczonych dwanaście. System ma rejestrować wypożyczenia i zwroty
oraz pilnować, by przestrzegano wymienionych powyżej reguł
(ograniczeń).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 22

DDD; identyfikacja klas poprzez

rzeczowniki

Identyfikacja klas poprzez identyfikację rzeczowników i fraz
rzeczownikowych w tekście specyfikującym wymagania użytkownika
jest jedną z podstawowych, powszechnie stosowanych technik.

Proces ten przebiega w dwóch etapach:

Identyfikacja potencjalnych klas np. poprzez podkreślenie
wszystkich rzeczowników i fraz rzeczownikowych w tekście
wymagań.

Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie
taka potrzeba. Nazwy przyszłych klas powinny być rozważane jako
rzeczowniki w liczbie pojedynczej.

Niektórzy analitycy konstruują dwie listy potencjalnych
kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie
potrzeby z listy na listę. Taka technika chroni przed utratą
informacji, być może przydatnej krok dalej.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 23

Redukcja zbioru potencjalnych

kandydatów

Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa):

jest redundantny – tzn. gdy istnieją różne rzeczowniki dla określenia
tego samego bytu; trzeba tu brać pod uwagę następujący fakt: byty
mogą być podobne, ale niekoniecznie dokładnie takie same, a to z
kolei może wskazywać na związek generalizacji-specjalizacji
istniejący między nimi;

jest nieuchwytny – trudno jest określić, co właściwie oznacza i w
jaką klasę miałby być odwzorowany – być może inne elementy języka
byłyby bardziej użyteczne do opisania go;
oznacza wydarzenie lub operację – tutaj pomocnicze może być
zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty,
zachowanie i tożsamość;

stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś,
np. rzeczowniki wymagania czy system używane są raczej w procesie
modelowania niż do reprezentowania bytów istniejących w
analizowanej dziedzinie problemowej;

oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy – z
reguły nie istnieje potrzeba do modelowania ich w postaci klasy;

oznacza atrybut – coś prostszego niż klasa, bez interesującego zachowania.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 24

DDD - identyfikacja klas; przykład

Przykład wymagań dla biblioteki:

Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy
tej samej książki. Tylko personel może wypożyczać czasopisma.
Członek biblioteki może mieć jednocześnie wypożyczonych sześć
pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich
wypożyczonych dwanaście. System ma rejestrować wypożyczenia i
zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł
(ograniczeń).

Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, personel

Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system (wyrażenie
metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel,
reguła (nieuchwytne), ograniczenie (nieuchwytne)

Każdy rzeczownik, kandydat na przyszłą klasę, jest rozważany w liczbie pojedynczej.

pozycja (?), wypożyczenie (?), zwrot (?),

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 25

Identyfikacja generalizacji-

specjalizacji

Osoba

Person

el

Członek

bibl.

Książka

Egzemplarz

książki

Książ

ka

Czasopismo

Pozycja

Identyfikacja związków generalizacji-specjalizacji

Egzemplarz książki nie jest
rodzajem pozycji wydawniczej,
jaką

oznacza

tu

każde

wystąpienie klasy Książka.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 26

Identyfikacja asocjacji (1)

Identyfikacja asocjacji: podobnie, jak klasy można identyfikować
poprzez wyszukiwanie rzeczowników (czy fraz rzeczownikowych) w
tekście wymagań, tak asocjacje mogą być identyfikowane poprzez
wyszukiwanie w tym tekście czasowników (fraz czasownikowych).

Z przykładu z biblioteką moglibyśmy wydedukować następujące
asocjacje: “wypożyczył”, “zwrócił”, “jest egzemplarzem”,. Nie wszystkie
wystąpiły “jawnie” – w postaci czasowników (czy fraz czasownikowych).

Klasę A z klasą B powinna połączyć asocjacja (o pewnej
semantyce) jeżeli w czasie działania programu:

 obiekt klasy A wysyła komunikat do obiektu klasy B,

 obiekt klasy A tworzy obiekt klasy B (wywołuje konstruktor),

 obiekt klasy A posiada atrybut będący obiektem (lub kolekcją obiektów) klasy B,

 obiekt klasy A otrzymuje komunikat z argumentem będącym obiektem klasy B.

Podsumowywując: jeśli obiekt klasy A musi mieć możliwość dostępu
do danych pewnego obiektu klasy B, to klasy A i B powinna połączyć
asocjacja (w większości przypadków).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 27

Identyfikacja asocjacji (2)

Uwaga – nie archiwizujemy tu wypożyczeń; fakt zwrotu książki jest
rejestrowany poprzez usunięcie powiązania wypożyczyła między
obiektami klas Osoba i Egzemplarz książki (przypadek 1-szy) lub tego
obiektu klasy Wypożyczenie, który opisuje zwrócony egzemplarz – wraz
z odpowiednimi powiązaniami (przypadek 2-gi).

Osoba

Egzemplarz

książki

wypożyczyła

0..1

*

Osoba

Wypożyczenie

Egzemplarz

książki

*

0..1

Preferowane jest rozwiązanie pierwsze – klasa Wypożyczenie nie
posiada żadnych własności, ani atrybutów ani operacji.

1

1

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 28

Identyfikacja asocjacji (3)

Sytuacja ulegnie zmianie, gdy do poprzednich wymagań dołożymy
sformułowanie: Książki mogą być wypożyczane na okres trzech
tygodni, wypożyczanie książek jest archiwizowane, co implikuje
konieczność pamiętania obu dat: wypożyczenia i zwrotu.

Osoba

Egzemplarz

książki

wypożyczyła

*

*

Wypożyczenie

data wypożyczenia
data zwrotu

{data zwrotu - data wypożyczenia <= 3 tygod.}

Osoba

Wypożyczenie

data wypożyczenia
data zwrotu

Egzemplarz

książki

*

*

{data zwrotu - data wypożyczenia
<= 3 tygod.}

Oba rozwiązania są poprawne, aczkolwiek
oba diagramy nie przenoszą dokładnie takiej
samej informacji.

1

1

Jak wyglądałby diagram,
gdyby nie archiwizowano
wypożyczeń?

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 29

Identyfikacja asocjacji (4)

Personel

Czasopismo

wypożyczył

0..1

*

Asocjacja wypożyczył między klasami Personel i Czasopismo

Książka

Egzemplarz

książki

1..*

Książka

Egzemplarz

książki

1..*

1

Asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki

Nie

archiwizuje

się

wypożyczeń dla czasopism,
ani nie zostały nałożone
żadne

ograniczenia

na

długość

okresu

wypożyczenia.

Kompozycja silniej podkreśla tu
związek istniejący między książką
(byt

wirtualny,

metadane),

a

konkretnym egzemplarzem.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 30

Diagram klas dla przykładowych

wymagań

Członek

bibl.

Personel

Pozycja

Czasopismo

Książka

Egzemplarz

książki

Osoba

/liczba wyp. akt. pozycji

*

0..1

{ liczba wyp. akt.
pozycji <= 12 }

{ liczba wyp. akt.
pozycji <= 6 }

1..*

Wypożyczenie

data wypożyczenia
data zwrotu

{ data zwrotu - data wypożyczenia
<= 3 tygodnie }

*

*

wypożyczył

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 31

Model obiektowy – uwagi (1)

Konstruując system zawsze należy mieć na uwadze dwa główne
cele, które powinny zostać osiągnięte:

 zbudowanie systemu (który spełni aktualne potrzeby klienta) tak
szybko i tanio, jak tylko jest to możliwe,

 zbudowanie systemu, który będzie łatwy do utrzymania
(konserwacji) i łatwo adaptowalny do przyszłych wymagań.

Pierwszy cel można osiągnąć poprzez wyróżnienie obiektów,
przypisanie im własności (atrybutów i zachowań), zgrupowanie ich
w klasy, czyli skonstruowanie modelu obiektowego, a następnie
zapewnienie

sensownej

realizacji

wymagań

klienta

(wyspecyfikowanych w modelu przypadków użycia) – poprzez
ustalenie dróg przesyłania komunikatów między obiektami w
systemie – tu będą pomocne diagramy dynamiczne.

Cel drugi można osiągnąć budując system modularny, złożony z
komponentów oprogramowania (klas, modułów, …) o wysokiej
kohezji (ang. high cohesion) i słabych skojarzeniach wzajemnych
(ang. low coupling).

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 6, Slajd 32

Model obiektowy - uwagi (2)

Identyfikując

klasy

(np.

poprzez

wyszukiwanie

rzeczowników w tekście wymagań) i asocjacje (poprzez
wyszukiwanie czasowników), nigdy nie należy tracić z
oczu perspektywy pojęciowej – skonstruowany model
obiektowy

nie

może

zniekształcać

relacji

istniejących w analizowanej rzeczywistości, tzn. w
tym fragmencie dziedziny problemowej, którym zajmuje
się tworzony system.

Osoby, znające dziedzinę problemową, nie mogą być
narażone na nieprzyjemne niespodzianki !

Ważne: