Projektowanie system

1


Projektowanie systemów informacyjnych
Wyklad 12
Budowa modelu obiektowego podsumowanie
Ewa Stemposz, Kazimierz Subieta Instytut
Podstaw Informatyki PAN, Warszawa Polsko-Japons
ka Wyzsza Szkola Technik Komputerowych, Warszawa
2
Zagadnienia
Strategie w budowie modelu obiektowego

• top-down
• bottom-up
• inside-out

Analiza - kolejne kroki Kryteria jakosci modelu
obiektowego Proponowana miara dla oceny modelu
obiektowego (diagramu klas)
3
Budowa modelu obiektowego strategia top-down
Od ogólu do szczególu (top-down) - najpierw
definiuje sie pojecia ogólne, a nastepnie
uszczególawia je w kolejnych krokach
(wykorzystujac pojecia elementarne, tzw.
prymitywy).
Kolejne rozwiniecia sa coraz bardziej szczególowe
4
Strategia top-down prymitywy (1)
KLASA gt KLASY POWIAZANE
KLASA gt SPECJALIZACJE
KLASAgt KILKA KLAS NIEZALEZNYCH
ASOCJACJAgt ASOCJACJE RÓWNOLEGLE
5
Strategia top-down prymitywy (2)
ASOCJACJAgt KLASA Z ASOCJACJA
UZUPELNIENIE O ATRYBUTY
A1 A2 B1 B2
ROZWINIECIE ATRYBUTÓW
UZUPELNIENIE O METODY
6
Strategia top-down przyklady (1)
MIASTO
MIEJSCE
WOJEWÓDZTWO
PRACOWNIK
NAGRODA
7
Strategia top-down przyklady (2)
DANE DEMOGRAFICZNE
1
DANE O TERENIE
DANE O MIESZKANCACH
2
mieszka w
3
MIEJSCE
OSOBA
urodzila sie w
ZAGRANICA
MIASTO W KRAJU
MEZCZYZNA
KOBIETA
znajduje sie w
WOJEWÓDZTWO
8
Budowa modelu obiektowego strategia bottom-up

• Od szczególu do ogólu (bottom-up) - najpierw
  definiuje sie pojecia elementarne, a nastepnie
• buduje sie z nich struktury w celu stworzenia
  pojec ogólnych.

9
Strategia bottom-up przyklad
MIASTO W KRAJU
WOJEWÓDZTWO
KOBIETA
ZAGRANICA
MEZCZYZNA
OSOBA
MIASTO W KRAJU
znajduje sie w
MEZCZYZNA
KOBIETA
MIEJSCE
WOJEWÓDZTWO
zwiazana z
MIEJSCE
OSOBA
ZAGRANICA
MIASTO W KRAJU
10
Strategia inside-out

• Rozprzestrzenianie (inside-out) - najpierw
  definiuje sie pojecia, które wydaja sie byc
• najwazniejsze, a nastepnie rozwija sie je
  poprzez dobudowywanie kolejnych pojec, które
• stanowia ich uzupelnienie.

WYMAGANIA
POJECIA NAJWAZNIEJSZE
W istocie, strategie projektowania sa zwykle
oparte na rozprzestrzenianiu, z inklinacja do
top-down lub bottom-up.
Diagram wstepny
DIAGRAMY (coraz szersze)
Diagramy posrednie
DIAGRAM KONCOWY
11
Analiza - kolejne kroki

• Pierwszy przebieg zidentyfikuj klasy i ich
  atrybuty.

Udokumentuj je w modelu obiektowym i slowniku
danych!

• Drugi przebieg Usun niepotrzebne klasy i dodaj
  dziedziczenie.

Udokumentuj to w modelu obiektowym i slowniku
danych!

• Trzeci przebieg Dodaj asocjacje, dokonaj
  uszczególowienia asocjacji wprowadz oznaczenia
  licznosci asocjacji, dodaj atrybuty (lub klasy
  asocjacji) zwiazane z asocjacjami, wyszukaj
  ewentualne relacje zawierania sie (agregacje i
  kompozycje), wyszukaj asocjacje
• kwalifikowane.

Udokumentuj to w modelu obiektowym i slowniku
danych!

• Czwarty przebieg dodaj metody do klas poprzez
  zbudowanie modelu dynamicznego. Jezeli jestes z
  siebie zadowolony, przejdz do fazy projektowania
  w przeciwnym wypadku idz z powrotem do drugiego
  przebiegu.

Udokumentuj to w modelu obiektowym i slowniku
danych!
12
Zidentyfikuj potencjalne klasy

• Zidentyfikuj kandydujace rzeczowniki - ze
  sformulowania problemu w specyfikacji
• wymagan uzytkownika - jako potencjalne klasy.
• Szukaj transakcji, zdarzen, ról i rzeczy
  dotykalnych, np.

transakcje pozyczka, spotkanie,
sprzedaz, zdarzenia ladowanie, zapytanie, role
matka, ojciec, nauczyciel, pasazer, rzeczy
dotykalne samochód, czujnik, skladnik, samolot.

• Zidentyfikuj potencjalne kolekcje (zbiory).
  Pewne rzeczowniki implikuja kolekcje i moga
• stac sie kontenerami (container). Kolekcje
  wymagaja specjalnego traktowania.

Np. Kazdy dostep jest rejestrowany w dzienniku.
Ergo dziennik jest kolekcja.

• Zidentyfikuj obiekty stanowiace pogranicze
  systemu obiekty dostepne dla innych systemów,
  linie komunikacyjne, urzadzenia peryferyjne,
  obiekty wejscia/wyjscia,...

13
Zidentyfikuj potencjalne atrybuty

• Rzeczownik moze byc atrybutem, jezeli nie mozna
  przypisac mu atrybutów ani - interesujacego z
  punktu widzenia celów projektowanego systemu -
  zachowania.
• Rzeczownik moze byc atrybutem, jezeli
  wyjasnienie jego znaczenia zmusza do odwolania
  sie do jakiegos innego rzeczownika (oznaczajacego
  obiekt). Np. rzeczownik kolor zmusza do zadania
  pytania kolor czego?.
• Potencjalny atrybut moze ostatecznie okazac sie
  asocjacja miedzy klasami, np. atrybut
  NazwaFirmy w klasie Pracownik na etapie tworzenia
  schematu pojeciowego jest modelowany jako
  asocjacja miedzy klasami Firma i Pracownik.

Zidentyfikuj klase lub asocjacje, która jest
najlepszym kandydatem jako wlasciciel atrybutu.
14
Dokumentuj swoje ustalenia!

• Utwórz szkic projektu w postaci modelu
  obiektowego wysokiego poziomu, (najlepiej przy
  uzyciu narzedzi CASE).
• Twórz nowy model obiektowy dla kazdego kroku
  iteracyjnego. Staraj sie równolegle budowac model
  przypadków uzycia i model dynamiczny.
• Pracuj nad slownikiem danych.

Dla kazdej klasy
Sformuluj cel istnienia tej klasy. Opisz te
klase. Ustal Kto/co tworzy obiekty klasy.
Kto/co usuwa obiekty klasy.
Kto/co modyfikuje obiekty klasy.
Kto/co zawiera obiekty klasy. Wypisz asocjacje
klasy z innymi klasami. ------------------
PROJEKTOWANIE ------------------------ Wypisz
interfejsy wspomagane (realizowane) przez
klase. Wypisz widoczne publicznie atrybuty i
metody. Wypisz dziedzine wartosci dla kazdego
atrybutu w klasie.
15
Dodaj dziedziczenie

• Wyciagnij przed nawias wszelkie wspólne
  wlasnosci (metody i atrybuty) kilku
  semantycznie powiazanych klas.
• Zgrupuj te wspólne wlasnosci w jedna nadklase.
• Nazwij te nadklase w taki sposób, aby kazda
  klasa pochodna mogla byc uwazana za jej
  podklase. Np. pies jest nadklasa, pekinczyk,
  jamnik, pudel sa podklasami klasy pies.

Ekstensje podklas moga miec puste lub niepuste
przeciecia. Oznacz je odpowiednio. Obiekt,
nalezacy do przeciecia, dziedziczy z obu podklas.
K1
EK1
EK2
K
K2
K1
EK1
EK2
K
K2
overlapping
16
Dodaj asocjacje
Wystapienia asocjacji sa zwiazkami zachodzacymi
pomiedzy obiektami. Dowolna zaleznosc pomiedzy
obiektami moze byc zamodelowana jako asocjacja.
Wiele asocjacji moze powstac jako efekt wynikly z
analizy modelu dynamicznego - rozwijaj wiec ten
model.

• Przetestuj sciezki dostepu niekiedy dostep do
  jednego obiektu wymaga dostepu do innego, co
  implikuje asocjacje miedzy odpowiednimi klasami.
• Dodaj oznaczenia licznosci do asocjacji.
• Zidentyfikuj role dla asocjacji rekurencyjnych
  (w ramach tej samej klasy), ternarnych, itd.
• Sprawdz, czy asocjacja ma prowadzic do danej
  klasy, czy tez raczej do jej podklasy lub
• nadklasy.
• Dodaj atrybuty zwiazane z wprowadzona asocjacja.
• Jezeli asocjacja ma charakter czesc-calosc,
  zamien ja na agregacje lub kompozycje.

Udokumentuj te ustalenia w modelu obiektowym i w
slowniku danych!
17
Przygotowanie slownika
Przygotowanie slownika stanowi bardzo istotny
element kazdego projektu. Pojedyncze slowa moga
miec bardzo rózne interpretacje, mimo pozornej
zgodnosci. Nalezy dazyc do maksymalnego
uproszczenia, ujednolicenia i jednoznacznej
interpretacji.
Unikac synonimów np. uzywania w tym samym
projekcie slów traktor i ciagnik. Unikac
homonimów uzywania tego samego slowa dla
okreslenia dwóch róznych bytów, np. asocjacja
Kierownik i atrybut Kierownik
Przyklad slownika
Klient - pojedyncza osoba, malzenstwo, osoba
prawna. Konto - sluzy do rejestrowania zasobów i
wyników transakcji przeprowadzanych przez
klienta, bedacego wlascicielem konta. Konta moga
byc róznych typów, a w szczególnosci konta
indywidualne, malzenskie, firmowe i inne. Kazdy
klient moze posiadac wiecej niz jedno konto.
Pojedyncze konto przypisane jest do dokladnie
jednego klienta. Bank - instytucja finansowa
zarzadzajaca kontami klientów, wydajaca karty
bankowe, udzielajaca kredytów i prowadzaca inne
operacje finansowe. Kasjer - pracownik banku
posiadajacy uprawnienia do obslugi kont klientów.
18
Zawartosc slownika danych
Nie istnieja standardy dotyczace sposobu
specyfikowania zawartosci slownika danych. Mozna
wykorzystywac do tego celu np. zaadaptowana
notacje BNF (Backus-Naur-Form). BNF jest uzywana
glównie do opisu skladni jezyków programowania.
Mozna wykorzystywac nastepujace symbole
struktura danych po lewej stronie symbolu
sklada sie z elementów wyspecyfikowanych po
stronie prawej,
odpowiada slowu i wykorzystywane do
agregowania elementów,
definiowana struktura zawiera tylko jeden
sposród elementów zawartych w nawiasach i
oddzielonych srednikami,
definiowana struktura zawiera od 0..
wystapien elementu zawartego w nawiasach ,
( ) elementy zawarte w nawiasach ( ) sa
opcjonalne co oznacza, ze maja 0..1 wystapien,
informacje zawarte miedzy sa
traktowane jak komentarz, a wiec nie stanowia
elementów skladowych definiowanej struktury.
19
Przyklady specyfikowania
1
Zamówienie NrZamówienia DataZamówienia
NazwaOdbiorcy NazwaSprzedawcy NrProduktu
NazwaProduktu Cena Ilosc WartoscProduktu
(SumarycznaWartoscZamówienia)
2
Zamówienie NrZamówienia DataZamówienia
NazwaOdbiorcy NazwaSprzedawcy
PozycjaZamówienia (SumarycznaWartoscZamówienia
PozycjaZamówienia NrProduktu NazwaProduktu
Cena Ilosc WartoscProduktu
20
Czy masz prawidlowe klasy? (1)

• Klasy nadmiarowe. Jezeli dwie klasy wyrazaja te
  sama informacje, wówczas powinna byc wybrana ta,
  która jest bardziej informatywna. Np. w systemie
  dla linii lotniczej moga byc klasy Klient i
  Pasazer, ta druga jest bardziej informatywna.
• Klasy nierelewantne. Jezeli klasa ma niewielki
  zwiazek z problemem, wówczas powinna byc
  pominieta, szczególnie na wyzszych poziomach
  abstrakcji.
• Klasy niejasne. Klasy powinny byc jednoznacznie
  okreslone. Np. klasa Podmiot_obslugi moze byc
  rozumiana jak Klient, Bank, Pasazer, Firma, itd.
• Atrybuty przypisane do klas charakteryzuja
  pojedyncze obiekty lub grupy obiektów danej
  klasy. Jezeli atrybut moze istniec niezaleznie od
  obiektu, byc moze lepsze byloby zrobienie z
  niego klasy, np. atrybut Dzieci_pracownika dla
  klasy Pracownik.
• Operacje przypisane do klas dzialaja na
  pojedynczych obiektach lub zbiorach obiektów. W
  niektórych sytacjach operacja moze w
  ostatecznosci okazac sie klasa. Np.
  Rozmowa_telefoniczna moze byc operacja, ale moze
  byc takze klasa z atrybutami takimi jak czas,
  dlugosc, taryfa, itd.

21
Czy masz prawidlowe klasy? (2)

• Klasa zamiast roli asocjacji. Nazwa klasy
  powinna wyrazac jej istotny charakter, a nie role
  jaka pelni w zwiazku z inna klasa. Np.
  Wlasciciel, jako okreslenie osoby posiadajacej
  samochód, jest niewlasciwie wybrana nazwa
  klasy, poniewaz jest to rola jaka pelni osoba w
  asocjacji z samochodem. Osoba moze byc
  polaczona poprzez inne asocjacje np. ze swoimi
  dziecmi, i wtedy taka nazwa klasy okaze sie
  nieodpowiednia i niezrozumiala.
• Klasy odnoszace sie do implementacji. Nalezy ich
  unikac. Model pojeciowy nie powinien zawierac
  elementów projektowych (implementacyjnych).
  Laczenie klas takich jak Osoba, Firma, Budynek z
  klasami takimi jak Okno_dialogowe, Modul, Plik,
  Zapis, Dokument, Proces, Algorytm, Tablica,
  Wyjatek, Przerwanie, itd. powoduje, ze diagram
  staje sie calkowicie nieczytelny. W takiej
  sytuacji nalezy raczej zdecydowac sie na dwa
  diagramy, jeden ze swiata przedmiotu systemu
  informatycznego (dziedziny problemowej), drugi ze
  swiata jego wnetrza, oraz powiazac te dwa
  diagramy ze soba, np. przy pomocy nieformalnego
  opisu lub poprzez specjalnie przygotowany
  formularz.

22
Czy masz prawidlowe atrybuty? (1)
Zwykle atrybuty nie sa wystarczajaco dokladnie
opisane w tekscie wymagan. Czesto trzeba je
okreslac posrednio w oparciu o inne informacje
wynikajace z wymagan, z charakterystyk operacji
zachodzacych na obiektach czy w ostatecznosci z
wiedzy dziedzinowej. Na szczescie, rzadko
wplywaja na podstawowa strukture modelu.

• Klasa zamiast atrybutu. Jezeli pewna wlasnosc
  posiada niezalezne znaczenie, powinna byc
  modelowana jako klasa - moze wtedy brac udzial w
  zwiazkach z innymi klasami. Np. Adres jest raczej
  (?) klasa niz atrybutem, natomiast Nazwisko,
  Zarobek sa atrybutami.
• Identyfikatory. Model obiektowy zapewnia
  unikalna tozsamosc obiektów, dlatego z reguly,
  atrybuty stanowiace identyfikatory obiektów sa
  zbedne. Specyfikuje sie jedynie te z nich,
  które wystepuja explicite w dziedzinie
  problemowej (np. PESEL dla osoby).
• Atrybuty asocjacji. Sa zwykle oczywiste w
  przypadku asocjacji m n. Dla asocjacji n 1 i
  1 1 nie jest to juz tak oczywiste. Mozna
  stosowac myslowy eksperyment Co by bylo gdyby
  ta asocjacja bylaby m n ? Np. atrybut zarobek
  w klasie Pracownik stal by sie wtedy atrybutem
  asocjacji miedzy klasami Pracownik i Firma.

23
Czy masz prawidlowe atrybuty? (2)

• Atrybuty wewnetrzne. Jezeli atrybut ma charakter
  wewnetrzny (jest niewidoczny) to nalezy go
  raczej wyeliminowac z modelu pojeciowego. Np.
  dla metody oblicz_podatek moga istniec
  wewnetrzne atrybuty przechowujace podatek
  obliczony dla kolejnych lat.
• Atrybuty nieistotne. Omijaj w modelu. Np.
  atrybut Uwagi do obiektu, który nie
  uczestniczy w zadnej istotnej operacji na
  obiekcie (poza zapisaniem i wyswietlaniem tego
  atrybutu).
• Atrybuty tzw. rozszczepiajace (dyskryminatory).
  Jezeli atrybut ma charakter dzielacego ekstensje
  danej klasy na grupy o róznej semantyce, to
  zastap go specjalizacjami klas (tzw. podzial
  poziomy klasy). Np. atrybut rodzaj_pracownika z
  wartosciami uczen, stazysta, etatowy,
  na_zlecenie, emerytowany. Dosc czesto takie
  atrybuty powstaja wskutek przedwczesnych decyzji
  implementacyjnych.
• Atrybuty odnoszace sie do implementacji. Nalezy
  je wyeliminowac z modelu analizy. Przykladem
  sa atrybuty, takie jak format pliku graficznego
  ze zdjeciem pracownika, rozmiar obiektu w
  bajtach, przyjeta czestosc skladowania obiektu,
  itp.

24
Co moze sugerowac, ze brakuje pewnych klas?

• Asymetria w asocjacjach i generalizacjach.
  Nalezy dodac nowe klasy poprzez analogie.
• Rozlaczne grupy atrybutów i operacji wewnatrz
  klasy. Nalezy rozdzielic taka klase na kilka
  innych (tzw. podzial pionowy klasy).
• Trudnosci z generalizacja. Jedna klasa moze
  pelnic dwie zasadniczo rózne role. Np. klasa
  Ksiazka z jednej strony, sa operacje odnoszace
  sie do ksiazki, jak do konkretnego egzemplarza,
  z drugiej strony - operacje odnoszace sie do
  ksiazki, jak do pozycji wydawniczej.
• Istnienie operacji, której nie da sie zastosowac
  do zadnej z istniejacych juz klas. Nalezy dodac
  brakujaca klase.
• Zdublowane asocjacje o tej samej semantyce i
  strukturze. Sugeruja, ze warto utworzyc klase
  bardziej ogólna i skorzystac z mozliwosci
  dziedziczenia asocjacji.
• Pewna rola klasy zdecydowanie zmienia jej
  charakter. Byc moze powinna byc oddzielna klasa.
  Np. rola samochodu w zwiazku ze zlomowiskiem
  przestaja miec znaczenie stare atrybuty, a
  nabieraja znaczenia nowe, takie jak np. waga
  metali, zdolnosc do recyclingu, itd.

25
Czy masz prawidlowe asocjacje? (1)

• Asocjacje zwiazane z likwidowana klasa. Jezeli
  klasa jest eliminowana z modelu, to wszystkie
  asocjacje z nia zwiazane sa równiez eliminowane.
  W takich sytuacjach nalezy rozpatrzyc, czy nie
  powinny byc jednak przylaczone do innych klas.
• Asocjacje nierelewantne lub implementacyjne.
  Nalezy wyeliminowac z modelu pojeciowego te
  asocjacje, które nie odnosza sie do dziedziny
  problemowej.
• Akcje (czynnosci, procesy) jako asocjacje.
  Asocjacje powinny opisywac strukturalne wlasnosci
  dziedziny problemowej, a nie aspekt dzialania
  bytów istniejacych w dziedzinie problemowej. Np.
  weryfikacja_klienta opisuje interakcje pomiedzy
  obiektem Kasjer (lub aktorem Kasjer) a obiektem
  Klient, a nie zwiazek pomiedzy tymi obiektami
  (chyba ze chcemy rejestrowac kto, kogo i kiedy
  weryfikowal). Bardzo czesty blad.
• Asocjacje 3-arne, 4-arne, itd. Nalezy traktowac
  je podejrzliwie i dekomponowac na asocjacje
  binarne poprzez wprowadzenie klasy
  posredniczacej (?).

Klasa posredniczaca
26
Czy masz prawidlowe asocjacje? (2)

• Asocjacje pochodne. Unikac asocjacji, które
  wynikaja z innych asocjacji. Podobnie, jezeli
  asocjacja wynika z wartosci atrybutów, mozna
  wyeliminowac albo te asocjacje, albo którys z
  atrybutów. Nalezy bardzo uwazac, poniewaz
  niekiedy wynikanie jest pozorne.

Wszystkie asocjacje sa tu niezbedne. Asocjacji
zatrudnia nie mozna wydedukowac z dwóch
pozostalych, poniewaz moga byc pracownicy bez
przydzielonego komputera.
zatrudnia
1

Firma
Osoba
0..1
1
posiada


Komputer
jest_przydzielony

• Dodawanie nazw ról, kiedy jest to wlasciwe. Np.
  pomiedzy Firma i Osoba dla asocjacji
  pracuje_dla warto dodac role pracodawca i/lub
  pracownik, aby uniknac watpliwosci kto dla
  kogo pracuje ( lub wykorzystac symbol ).

27
Czy masz prawidlowe asocjacje? (3)

• Kwalifikowane asocjacje. Czesto, pewien atrybut
  powiazany z asocjacja posiada unikatowe
  znaczenie, pozwalajac na jednoznaczny podzial
  zbioru obiektów (na pojedyncze obiekty lub grupy
  obiektów). Np. kod_banku identyfikuje bank w
  ramach konsorcjum banków, w zwiazku z czym
  asocjacje np. kart bankowych z bankiem mozna
  kwalifikowac kodem banku. Warto oznaczyc taka
  sytuacje.
• Licznosc. Staraj sie wprowadzic licznosc do
  diagramów, ale nie przywiazuj do tego zbytniej
  wagi na poczatku analizy, poniewaz licznosci
  bardzo czesto ulegaja zmianie w miare rozwijania
  projektu.
• Opuszczone asocjacje. Staraj sie zidentyfikowac
  je na podstawie atrybutów (moga z nich wynikac),
  na podstawie diagramów dynamicznych lub
  scenariuszy interakcji aktorów z systemem.

28
Za malo lub za duzo asocjacji?
Model moze zawierac zbyt malo lub zbyt duzo
asocjacji, gdy

• Brak sciezki dostepu do pewnych obiektów. Mozemy
  to stwierdzic próbujac konstruowac zapytanie.
• Redundantna informacja w asocjacji. Zastanowic
  sie, czy jest potrzebna.
• Brak operacji, które wykorzystuja dana
  asocjacje. Jezeli nie mamy operacji lub zapytan,
  które efektywnie uzywaja asocjacji, wówczas
  prawdopodobnie jest ona zbedna.

W praktyce, rzadko udaje sie wypracowac
dostatecznie rygorystyczne reguly postepowania,
kóre prowadzilyby skutecznie do celu, czyli do
uzyskania modelu o zadawalajacej jakosci. Liczba
sytuacji, z którymi maja do czynienia analitycy,
jest ogromna i zawsze beda istniec przypadki,
kiedy omówione powyzej zalecenia nie wystarcza.
Ostatecznym kryterium jest wiec próba unikniecia
wszelkich niespójnosci i uzyskania pelnego
zadowolenia klienta. Dla wielu projektów jest to
i tak bardzo trudne do osiagniecia.
29
Kryteria jakosci modeli
Dobrej jakosci model powinien byc

• poprawny,
• kompletny,
• minimalny,
• czytelny,
• samo-tlumaczacy sie,
• podatny na modyfikacje.

Jednoczesne spelnienie wszystkich warunków jest
czesto niemozliwe, nie mniej jednak nalezy do
tego dazyc.
30
Poprawnosc
Model/diagram jest poprawny jezeli wszystkie
wystepujace na nim pojecia zostaly wlasciwie
uzyte.

• Poprawnosc syntaktyczna
• Pojecia sa prawidlowo zapisane/narysowane/powiazan
  e na diagramie.
• Poprawnosc semantyczna
• Diagram odpowiada sytuacji z modelowanej
  rzeczywistosci.
• Czeste bledy
• uzycie atrybutu zamiast klasy czy asocjacji lub
  odwrotnie,
• pominiecie uogólnienia lub specjalizacji,
• nieprawidlowa arnosc asocjacji (np. binarna
  zamiast n-narnej),
• uzycie klasy zamiast asocjacji lub odwrotnie,
• pominiecie atrybutów w asocjacjach,
• pominiecie lub nieprawidlowa licznosc asocjacji.

31
Kompletnosc
Model/diagram jest kompletny jezeli wszystkie
cechy opisywanego obszaru sa na nim wyrazone.

• Jak to sprawdzic ?
• dokladnie, szczególowo przejrzec specyfikacje
  wymagan dotyczacych opisywanego obszaru i
  sprawdzic czy sa one wyrazone na diagramie,
• przejrzec pojecia zobrazowane na diagramie i
  sprawdzic ich opisy w wymaganiach,
• próbowac porównywac ze soba diagram klas i
  diagramy dynamiczne sprawdzajac ich zgodnosc i
  spójnosc.

32
Minimalnosc

• Model/diagram jest minimalny jezeli kazdy z
  aspektów wymagan analizowanego obszaru wystepuje
  na schemacie tylko raz. Usuniecie dowolnego
  elementu z diagramu minimalnego powoduje utrate
  informacji.

Redundancja informacji jest czasami korzystna.
Nalezy wtedy udokumentowac, które elementy sa
pochodnymi innych i w jaki sposób sie je wylicza
lub wyprowadza.
PRACOWNIK Imie Nazwisko Data_ur
PRACOWNIK Imie Nazwisko Data_ur


pracuje_nad
pracuje_nad
kieruje
kieruje
0..1
0..1
PROJEKT ID_projektu Kierownik Liczba_prac
PROJEKT ID_projektu
Atrybuty Liczba_prac (liczba pracowników w
projekcie) i Kierownik dubluja informacje
zawarta w asocjacjach.
33
Czytelnosc
Model/diagram jest czytelny jezeli graficzna
reprezentacja zawiera minimum punktów percepcji
(przeciec, zalaman linii, itp.).
Kryteria czytelnosci elementy w punktach rastru,
ta sama wielkosc elementów, linie diagramu
biegnace poziomo i/lub pionowo, minimalna liczba
przeciec lini, symetria, itp.
A-E
B
A-C
A-E
A
A
A-D
B-D
B-C
A-C
A-D
E
C
D
B-E
D-B
D
C
E
B
C-B
E-B
34
Samo-tlumaczenie (1)
Model/diagram jest samo-tlumaczacy sie
(samo-opisowy) jezeli wymagania analizowanego
obszaru sa reprezentowane na schemacie w
naturalny sposób, sa zrozumiale i na tyle
wyczerpujace, ze nie wymagaja dodatkowych
wyjasnien.

prowadzi
PROFESOR
SEMINARIUM
prowadzi
oferuje
WYKLAD
ASYSTENT
objasnia
prowadzi
ZAJECIA
NAUCZYCIEL
SEMINARIUM
WYKLAD
PROFESOR
ASYSTENT
35
Samo-tlumaczenie (2)

• Model/diagram jest samo-tlumaczacy sie takze, gdy
  nie istnieje potrzeba stosowania innych
  formalizmów (np. opisów slownych), dodatkowych w
  stosunku do notacji pojeciowych modelu danych, w
  celu reprezentowania cech analizowanego obszaru.

PACJENT


PACJENT

jest_prowadzony
Opieka Rodzaj_opieki
jest_konsultowany

LEKARZ
LEKARZ

0..1
36
Proponowana miara dla oceny diagramu klas (1)
Przedmiot oceny czastkowej
Ocena
1. Poprawnosc (suma ocen z punktów 1.1 - 1.7)
0 - 20
1.1 poprawna identyfikacja klas odejmowanie
punktów za np. brak klasy, za umieszczenie klasy
zamiast atrybutu czy asocjacji (takze w sytuacji
odwrotnej), za wprowadzenie do diagramu aktora
systemu (?), za bledna nazwe klasy (z reguly
rzeczownik w liczbie pojedynczej)
0 - 3
1.2 poprawne identyfikacja atrybutów i
specyfikacja ich rodzaju (opcjonalny,
powtarzalny, pochodny, klasowy) odejmowanie
punktów takze za wprowadzenie atrybutu zamiast
asocjacji (lub odwrotnie) czy zbyt detaliczna
specyfikacje
0 - 3
1.3 poprawne identyfikacja metod i
specyfikacja ich rodzaju (obiektu, klasowe)
odejmowanie punktów np. brak metod czy
wprowadzenie do diagramu metody generycznej
(utwórz, usun, czytaj, pisz), metody zamiast
atrybutu pochodnego, metody pochodnej (nie
istnieje !), za zbyt detaliczna specyfikacje
0 - 3
1.4 poprawne identyfikacja struktur i rodzaju
dziedziczenia (rozlaczne, nierozlaczne,
kompletne, niekompletne, jednoaspektowe,
wieloaspektowe, jednokrotne, wielokrotne,
dynamiczne) oraz rozmieszczenie atrybutów i metod
w ramach jednej hierarchii odejmowanie punktów
za np. brak hierarchii, nieprawidlowa
organizacje hierarchii (np. klasy o róznej
semantyce w jednej hierarchii, zamiana ról
podklas-nadklasa, obecnosc petli w strukturze,
brak oznaczenia dla klasy abstrakcyjnej,
0 - 3
37
Proponowana miara dla oceny diagramu klas (2)
Przedmiot oceny czastkowej
Ocena
wykorzystywanie tzw. obejsc ograniczen
srodowiska implementacji (np. asocjacja,
agregacja czy kompozycja zamiast dziedziczenia -
akcje odpowiednie dla etapu projektowania, a nie
analizy)
1.5 poprawna identyfikacja asocjacji wlasciwe
nazwy, wykorzystywanie ról, poprawne licznosci,
obecnosc atrybutów asocjacji (lub klas
asocjacji) odejmowanie punktów takze za
modelowanie czynnosci wykonywanych poza systemem
czy interakcji aktora z systemem jako asocjacji,
wprowadzanie asocjacji redundantnych (na skutek
nie uwzglednienia dziedziczenia asocjacji czy
nieprawidlowego oznaczenia asocjacji pochodnych),
wykorzystywanie elementów przynaleznych do fazy
projektowania (np. asocjacje skierowane czy
klucze obce zamiast asocjacji)
0 - 3
1.6 identyfikacja agregacji, kompozycji i
asocjacji kwalifikowanej
0 - 2
1.7 wprowadzanie ograniczen i komentarzy (ile i w
jakiej postaci)
0 - 3
2. Kompletnosc
0 - 2
3. Minimalnosc
0 - 2
5. Czytelnosc
0 - 1
6. Samo-tlumaczenie nazwy dobrze przenosza
semantyke bytów
0 - 1
38
Proponowana miara dla oceny diagramu klas (3)
Przedmiot oceny czastkowej
Ocena
7. Organizacja
0 -5
8. Znajomosc notacji jezyka modelowania
0 - 1
9. Ocena laczna
0 - 32