Projektowanie systemów informacyjnych

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

koszt

liczenia,

częstość

zmian

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

(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

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

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

wykorzystanie

klas

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

obiektowego

podejścia

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

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ę

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

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

Członek

bibl.

Książka

Egzemplarz

książki

Książ

Czasopismo

Pozycja

Identyfikacja związków generalizacji-specjalizacji

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

oznacza

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.

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.

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

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

długość

okresu

wypożyczenia.

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

wirtualny,

metadane),

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:

Document Outline