Projektowanie systemów informacyjnych

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 12, 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 12

Budowa modelu obiektowego:
podsumowanie

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

Zagadnienia

Strategie w budowie modelu obiektowego:

 top-down

 bottom-up

 inside-out

Analiza – kolejne kroki
Kryteria jakości modelu obiektowego
Proponowana miara dla oceny modelu obiektowego
(diagramu klas)

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

Budowa modelu obiektowego;

strategia top-down

Kolejne

rozwinięcia są

coraz bardziej

szczegółowe

Od ogółu do szczegółu (top-down) – najpierw definiuje się pojęcia

ogólne, a następnie uszczegóławia je w kolejnych krokach

(wykorzystując pojęcia elementarne, tzw. prymitywy).

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

Strategia top-down; prymitywy (1)

KLASA => KLASY POWIĄZANE

KLASA => SPECJALIZACJE

KLASA=>

KILKA KLAS NIEZALEŻNYCH

ASOCJACJA=>

ASOCJACJE RÓWNOLEGŁE

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

Strategia top-down; prymitywy (2)

ASOCJACJA=>

KLASA Z ASOCJACJĄ

UZUPEŁNIENIE O ATRYBUTY

ROZWINIĘCIE ATRYBUTÓW

A
B

A1
A2
B1
B2

UZUPEŁNIENIE O METODY

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

Strategia top-down; przykłady (1)

PRACOWNIK

NAGRODA

NOBLA

NAGRODA

OSCARA

MIEJSCE

WOJEWÓDZTWO

MIASTO

UMYSŁOWY

PRACOWNIK

FIZYCZNY

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

Strategia top-down; przykłady (2)

MĘŻCZYZNA

mieszka w

urodziła się w

MIEJSCE

OSOBA

DANE

DEMOGRAFICZNE

DANE O

MIESZKAŃCACH

DANE O

TERENIE

KOBIETA

ZAGRANICA

MIASTO W KRAJU

WOJEWÓDZTWO

znajduje się w

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

Budowa modelu obiektowego;

strategia bottom-up

Od szczegółu do ogółu (bottom-up) − najpierw definiuje się pojęcia elementarne, a następnie
buduje się z nich struktury w celu stworzenia pojęć ogólnych.

WYMAGANIA

WYMAGANIE n

WYMAGANIE 1

POJĘCIE 11

POJĘCIE 1m

POJĘCIE n1

POJĘCIE nk

DIAGRAM 11 DIAGRAM 1m

DIAGRAM n1

DIAGRAM nk

DIAGRAM 1

DIAGRAM n

KOŃCOWY

DIAGRAM

ZINTEGROWANY

. . . .

.....

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

Strategia bottom-up; przykład

MĘŻCZYZNA

MIEJSCE

OSOBA

KOBIETA

ZAGRANICA

MIASTO W KRAJU

WOJEWÓDZTWO

MĘŻCZYZNA

KOBIETA

ZAGRANICA MIASTO W KRAJU

OSOBA

MIEJSCE

związana z

MIASTO W KRAJU

WOJEWÓDZTWO

znajduje się w

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

Strategia inside-out

POJĘCIA

NAJWAŻNIEJSZE

DIAGRAMY

(coraz szersze)

WYMAGANIA

DIAGRAM

KOŃCOWY

Diagram wstępny

Diagramy

pośrednie

W istocie, strategie
projektowania są
zwykle oparte na
rozprzestrzeniani
u, z
inklinacją do top-
down
lub bottom-up.

Rozprzestrzenianie (inside-out) − najpierw definiuje się pojęcia, które
wydają się być najważniejsze, a następnie rozwija się je poprzez
dobudowywanie kolejnych pojęć, stanowiących ich uzupełnienie.

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

Analiza − kolejne kroki

 Pierwszy przebieg: zidentyfikuj klasy i ich własności (głównie atrybuty).

Udokumentuj je w modelu obiektowym i słowniku danych!

 Drugi przebieg: Usuń niepotrzebne klasy i dodaj dziedziczenie.

Udokumentuj to w modelu obiektowym i słowniku danych!

  Trzeci  przebieg:  Dodaj  asocjacje,  dokonaj  uszczegółowienia
asocjacji: wprowadź  oznaczenia liczności asocjacji, dodaj atrybuty (lub
klasy  asocjacji)  związane  z  asocjacjami,  wyszukaj  ewentualne  relacje
zawierania się (agregacje i kompozycje), wyszukaj asocjacje
kwalifikowane i asocjacje n-arne.

Udokumentuj to w modelu obiektowym i słowniku danych!

 Czwarty przebieg: dodaj metody do klas poprzez zbudowanie modelu
dynamicznego. Jeżeli jesteś z siebie zadowolony, przejdź do fazy
projektowania; w przeciwnym wypadku idź z powrotem do drugiego
przebiegu.

Udokumentuj to w modelu obiektowym i słowniku danych!

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

Zidentyfikuj potencjalne klasy

Rzeczy dotykalne: samochód, czujnik, składnik, samolot,
transakcje: pożyczka, spotkanie, sprzedaż,
zdarzenia: lądowanie, zapytanie,
role: matka, ojciec, nauczyciel, pasażer.

 Zidentyfikuj kandydujące rzeczowniki − ze sformułowania problemu
w specyfikacji
wymagań użytkownika − jako potencjalne klasy.

 Szukaj rzeczy dotykalnych, transakcji, zdarzeń i ról, np.:

 Zidentyfikuj potencjalne kolekcje (zbiory). Pewne rzeczowniki implikują kolekcje i mogą
stać się kontenerami (ang. container). Kolekcje wymagają specjalnego traktowania.

Np.: Każdy dostęp jest rejestrowany w dzienniku. Ergo: dziennik jest kolekcją.

 Zidentyfikuj obiekty stanowiące pogranicze systemu: obiekty
dostępne dla innych systemów, urządzenia peryferyjne, obiekty
wejścia/wyjścia, ...

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

Zidentyfikuj potencjalne atrybuty

 Rzeczownik może być atrybutem, jeżeli nie można przypisać mu ani
atrybutów ani − interesującego z punktu widzenia celów
projektowanego systemu − zachowania.

  Rzeczownik  może  być  atrybutem,  jeżeli  wyjaśnienie  jego  znaczenia
zmusza  do  odwołania  się  do  jakiegoś  innego  rzeczownika
(oznaczającego  obiekt).  Np.  rzeczownik  “kolor”  zmusza  do  zadania
pytania “kolor czego?”.

  Potencjalny  atrybut  może  ostatecznie  okazać  się  asocjacją  między
klasami,    np.  atrybut        NazwaFirmy  w  klasie  Pracownik  na  etapie
tworzenia  schematu  pojęciowego  jest    modelowany  jako  asocjacja
między klasami Firma i Pracownik.

Zidentyfikuj klasę lub asocjację,
która

jest

najlepszym

kandydatem do wystąpienia w
roli “właściciela” atrybutu.

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

Dokumentuj swoje ustalenia!

  Utwórz  szkic  projektu  w  postaci  modelu  obiektowego  wysokiego
poziomu, (najlepiej przy użyciu narzędzi CASE).
  Twórz  nowy  model  obiektowy  dla  każdego  kroku  iteracyjnego.
Staraj  się  równolegle  budować  model  przypadków  użycia  i  model
dynamiczny.
 Pracuj nad słownikiem danych.

Sformułuj cel istnienia klasy.
Opisz klasę.
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 realizowane przez klasę.
Wypisz widoczne publicznie atrybuty i metody.
Wypisz dziedzinę wartości dla każdego atrybutu w klasie.

Dla każdej klasy:

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

Usuń niepotrzebne klasy, dodaj

dziedziczenie

  Wyciągnij  przed  nawias  wszelkie  wspólne  własności  (metody  i
atrybuty) kilku    semantycznie powiązanych klas.
 Zgrupuj te wspólne własności w jedną nadklasę.
  Nazwij  tę  nadklasę  w  taki  sposób,  aby  każda  klasa  pochodna    mogła
być uważana za jej podklasę. Np. pies jest nadklasą, pekińczyk, jamnik,
pudel są podklasami  klasy pies.

Ekstensje podklas mogą mieć puste lub niepuste przecięcia. Oznacz je
odpowiednio. Obiekt, należący do przecięcia, posiada własności obu
podklas.

{overlapping}

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

Dodaj asocjacje

 Przetestuj ścieżki dostępu; niekiedy dostęp do jednego obiektu
wymaga dostępu do innego, co implikuje asocjację między odpowiednimi
klasami.

 Dodaj oznaczenia liczności do asocjacji.

 Zidentyfikuj role dla asocjacji rekurencyjnych (w ramach tej samej
klasy), ternarnych, itd.

 Sprawdź, czy asocjacja ma prowadzić do danej klasy, czy też raczej do
jej podklasy lub
nadklasy.

 Dodaj atrybuty związane z wprowadzoną asocjacją.

 Jeżeli asocjacja ma charakter “część-całość”, zamień ją na agregację
lub kompozycję.

 Oznacz asocjacje kwalifikowane.

Wystąpienia  asocjacji  są  związkami  zachodzącymi  pomiędzy
obiektami.  Dowolna  zależność  pomiędzy  obiektami  może  być
zamodelowana  jako  asocjacja.  Wiele  asocjacji  może  powstać
jako  efekt  wynikły  z  analizy  modelu  dynamicznego  −  rozwijaj
więc ten model.

Udokumentuj te ustalenia w modelu obiektowym i w
słowniku danych!

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

Przygotowanie słownika danych

Przygotowanie  słownika  danych  stanowi  bardzo  istotny  element
każdego projektu. Pojedyncze słowa mogą być różnie interpretowane,
przez  różne  osoby.  Należy  dążyć  do  maksymalnego  uproszczenia,
ujednolicenia  słownictwa,  co  powinno  prowadzić  do  jednoznacznej
interpretacji.

Unikać synonimów: np. używania w tym samym projekcie słów
traktor i ciągnik.
Unikać homonimów: używania tego samego słowa dla określenia
dwóch różnych bytów, np. asocjacja Kierownik i atrybut Kierownik.

Przykład
słownika Klient: pojedyncza osoba, małżeństwo, osoba prawna.

Konto:  służy  do  rejestrowania  zasobów  i  wyników  transakcji
przeprowadzanych przez klienta, będącego właścicielem konta.
Konta  mogą  być  różnych  typów,  a  w  szczególności:  konta
indywidualne,  małżeńskie,  firmowe  i  inne.  Każdy  klient  może
posiadać  więcej  niż  jedno  konto.  Pojedyncze  konto  przypisane
jest do dokładnie jednego klienta.
Bank:  instytucja  finansowa  zarządzająca  kontami  klientów,
wydająca  karty  bankowe,  udzielająca  kredytów  i  prowadząca
inne operacje finansowe.
Kasjer: pracownik banku posiadający uprawnienia do obsługi
kont klientów.

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

Zawartość słownika danych

Nie  istnieją  standardy  dotyczące  sposobu  specyfikowania  zawartości
słownika  danych.  Można  wykorzystywać  do  tego  celu  np.
zaadaptowaną  notację  BNF  (Backus-Naur-Form).  BNF  jest  używana
głównie do opisu składni języków programowania.

Można wykorzystywać następujące symbole:

= struktura danych po lewej stronie symbolu = składa się z
elementów wyspecyfikowanych po stronie prawej,

+ odpowiada słowu “i”; wykorzystywane do agregowania elementów,

[ … ] definiowana struktura zawiera tylko jeden spośród
elementów zawartych w nawiasach [ ] i oddzielonych
średnikami,

{ … } definiowana struktura zawiera od 0..* wystąpień elementu
zawartego w nawiasach { }; kolejne wystąpienia są rozdzielane
przecinkami,

( … ) elementy zawarte w nawiasach ( ) są opcjonalne co
oznacza, że mają 0..1 wystąpień,

* … * informacje zawarte między * * są traktowane jak
komentarz, a więc nie stanowią elementów składowych
definiowanej struktury.

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

Przykłady specyfikowania

Zamówienie = NrZamówienia + DataZamówienia + NazwaOdbiorcy +
NazwaSprzedawcy + {NrProduktu + NazwaProduktu + Cena + Ilość +
WartośćProduktu} + (SumarycznaWartośćZamówienia)

Zamówienie = NrZamówienia + DataZamówienia + NazwaOdbiorcy +
NazwaSprzedawcy + {PozycjaZamówienia} + (SumarycznaWartośćZamówienia}

gdzie:
PozycjaZamówienia = NrProduktu + NazwaProduktu + Cena + Ilość +
WartośćProduktu

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

Czy masz prawidłowe klasy? (1)

 Klasy nadmiarowe: Jeżeli dwie klasy wyrażają tę samą informację,
wówczas powinna być wybrana ta, która jest bardziej informatywna.
Np. w systemie dla linii lotniczej mogą być klasy Klient i Pasażer, ta
druga jest bardziej informatywna.

 Klasy nierelewantne: Jeżeli klasa ma niewielki związek z
problemem, wówczas powinna być pominięta, szczególnie na
wyższych poziomach abstrakcji.

 Klasy niejasne: Klasy powinny być jednoznacznie określone. Np.
klasa Podmiot_obsługi może być rozumiana jak Klient, Bank, Pasażer,
Firma, itd.

 Atrybuty przypisane do klas charakteryzują pojedyncze obiekty lub
grupy obiektów danej klasy. Jeżeli atrybut może istnieć niezależnie od
obiektu, być może lepsze byłoby zrobienie z niego klasy, np. atrybut
Dzieci_pracownika dla klasy Pracownik.

  Operacje  przypisane  do  klas  działają  na  pojedynczych  obiektach
lub  zbiorach  obiektów.  W  niektórych  sytacjach  operacja  może  w
ostateczności  okazać  się  klasą.  Np.  Rozmowa_telefoniczna  może  być
operacją,  ale  może  być  także  klasą  z  atrybutami  takimi  jak  czas,
długość, taryfa, itd.

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

Czy masz prawidłowe klasy? (2)

  Klasa  zamiast  roli  asocjacji:  Nazwa  klasy  powinna  wyrażać  jej
istotny  charakter,  a  nie  rolę  jaką  pełni  w  związku  z  inną  klasą.  Np.
Właściciel,  jako  określenie  osoby  posiadającej  samochód,  jest
niewłaściwie  wybraną  nazwą  klasy,  ponieważ  jest  to  rola  jaka  pełni
osoba w asocjacji z samochodem. Osoba może być połączona poprzez
inne  asocjacje np. ze swoimi dziećmi, i wtedy taka nazwa klasy okaże
się nieodpowiednia i  niezrozumiała.

 Klasy odnoszące się do implementacji: Należy ich unikać. Model
pojęciowy

nie

powinien

zawierać

elementów

projektowych

(implementacyjnych). Łączenie klas takich jak Osoba, Firma, Budynek
z  klasami  takimi  jak  Okno_dialogowe,  Moduł,  Plik,  Zapis,  Dokument,
Proces,  Algorytm,  Tablica,  Wyjątek,  Przerwanie,  itd.  powoduje,  że
diagram  staje  się  całkowicie  nieczytelny.  W  takiej  sytuacji  należy
raczej  zdecydować  się  na  dwa  diagramy,  jeden  ze  świata  przedmiotu
systemu  informatycznego  (dziedziny  problemowej),  drugi  ze  świata
jego  wnętrza,  oraz    powiązać  te  dwa  diagramy  ze  sobą,  np.  przy
pomocy  nieformalnego  opisu  lub  poprzez  specjalnie  przygotowane
formularze.

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

Czy masz prawidłowe atrybuty? (1)

Zwykle  atrybuty  nie  są  wystarczająco  dokładnie  opisane  w
tekście  wymagań.  Często  trzeba  je  określać  pośrednio:  w
oparciu  o  inne  informacje  wynikające  z  wymagań,  z
charakterystyk  operacji  zachodzących  na  obiektach  czy  w
ostateczności z wiedzy dziedzinowej.
Na szczęście, rzadko wpływają na podstawową strukturę modelu.

 Klasa zamiast atrybutu: Jeżeli pewna własność posiada niezależne
znaczenie, być może powinna być modelowana jako klasa − może wtedy
brać udział w związkach z innymi klasami. Np. Adres jest raczej (?) klasą
niż atrybutem, natomiast Nazwisko, Zarobek są atrybutami.

 Identyfikatory: Model obiektowy zapewnia unikalną tożsamość
obiektów, dlatego z reguły atrybuty stanowiące identyfikatory obiektów
są zbędne. Specyfikuje się jedynie te z nich, które występują explicite w
dziedzinie problemowej (np. PESEL dla osoby).

 Atrybuty asocjacji: Są zwykle oczywiste w przypadku asocjacji  m : n.
Dla asocjacji n : 1 i    1 : 1 nie jest to już tak oczywiste. Można stosować
myślowy  eksperyment:  “Co  by    było  gdyby  ta  asocjacja  byłaby  m  :  n  ?”
Np.  atrybut  zarobek  w  klasie  Pracownik  stał  by  się  wtedy  atrybutem
asocjacji między klasami: Pracownik i Firma.

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

Czy masz prawidłowe atrybuty? (2)

 Atrybuty wewnętrzne (pomocniczy): Jeżeli  atrybut  ma  charakter
wewnętrzny  (jest  niewidoczny)    to  należy  go  raczej  wyeliminować  z
modelu  pojęciowego.  Np.  dla  metody  oblicz_podatek  mogą  istnieć
wewnętrzne atrybuty przechowujące podatek obliczony dla kolejnych
lat.

 Atrybuty nieistotne: Omijaj w modelu. Np. atrybut: “Uwagi do
obiektu”, który nie uczestniczy w żadnej istotnej operacji na
obiekcie (poza zapisaniem i wyświetlaniem tego atrybutu).

  Atrybuty  tzw.  rozszczepiające  (dyskryminatory):  Jeżeli  atrybut
ma  charakter  dzielącego  ekstensję  danej  klasy  na  grupy  o  nieco
różnej  semantyce,  to  zastąp  go  specjalizacjami  klas  (tzw.  podział
poziomy klasy). Np. atrybut rodzaj_pracownika z wartościami: uczeń,
stażysta,  etatowy,  na_zlecenie,  emerytowany.  Dość  często  takie
atrybuty

powstają

wskutek

przedwczesnych

decyzji

implementacyjnych.

  Atrybuty  odnoszące  się  do  implementacji:  Należy  je
wyeliminować z modelu analitycznego.  Przykładem są atrybuty, takie
jak,  np.:  format  pliku  graficznego  ze  zdjęciem  pracownika,  rozmiar
obiektu w bajtach, przyjętą częstość składowania obiektów, itp.

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

Co może sugerować, że brakuje

pewnych klas?

 Rozłączne grupy atrybutów i operacji wewnątrz klasy: Należy
rozdzielić taką klasę na kilka innych (tzw. podział pionowy klasy).

 Trudności z generalizacją: Jedna klasa może pełnić dwie zasadniczo
różne role. Np. klasa Książka: z jednej strony, są operacje odnoszące się
do książki, jak do konkretnego egzemplarza, z drugiej strony są
operacje odnoszące się do książki, jak do pozycji wydawniczej.

 Istnienie operacji, której nie da się zastosować do żadnej z
istniejących już klas: Należy dodać brakującą klasę.

 Zdublowane asocjacje o tej samej semantyce i strukturze:
Sugerują, że warto utworzyć klasę bardziej ogólną i skorzystać z
możliwości dziedziczenia asocjacji.

  Pewna  rola  klasy  zdecydowanie  zmienia  jej  charakter:  Być  może
powinna  być    oddzielną  klasą.  Np.  rola  samochodu  w  związku  ze
złomowiskiem:  przestają  mieć    znaczenie  stare  atrybuty,  a  nabierają
znaczenia nowe, takie jak np. waga metali, zdolność  do  recyclingu, itd.

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

Czy masz prawidłowe asocjacje? (1)

  Asocjacje  związane  z  likwidowaną  klasą:  Jeżeli  klasa  jest
eliminowana z modelu, to   wszystkie jej asocjacje powinny być również
eliminowane.  W  takich  sytuacjach  należy      rozpatrzyć,  czy  jednak  nie
powinny być przyłączone do innych klas.

 Asocjacje nierelewantne lub implementacyjne: Należy
wyeliminować z modelu pojęciowego te asocjacje, które nie odnoszą
się do dziedziny problemowej.

  Akcje/czynności/procesy  jako  asocjacje:  Asocjacje  powinny
opisywać  strukturalne  własności  dziedziny  problemowej,  a  nie
aspekt  działania  bytów  w  niej  istniejących.  Np.  weryfikacja_klienta
opisuje  interakcję  pomiędzy  obiektem  Kasjer  (lub  aktorem  Kasjer)  a
obiektem  Klient,  a  nie  związek  pomiędzy  tymi  obiektami  (chyba  że
chcemy rejestrować: kto, kogo i kiedy weryfikował). Bardzo częsty błąd.

 Asocjacje 3-arne, 4-arne, itd. Należy traktować je podejrzliwie (?) i
dekomponować na asocjacje binarne poprzez wprowadzenie klasy
pośredniczącej (?).

Klasa pośrednicząca

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

Czy masz prawidłowe asocjacje? (2)

posiada

 Dodawanie nazw ról, kiedy jest to właściwe: Np. pomiędzy Firmą i
Osobą  dla  asocjacji  pracuje_dla  warto  dodać  role  pracodawca  i/lub
pracownik,  aby  uniknąć  wątpliwości    kto  dla    kogo  pracuje  (lub
wykorzystać symbol    ).

  Asocjacje  pochodne:  Należy  unikać  asocjacji,  które  wynikają  z  innych
asocjacji.  Podobnie,  jeżeli  asocjacja  wynika  z  wartości  atrybutów,  można
wyeliminować  albo  tę  asocjację,  albo  któryś  z  atrybutów.  Należy  bardzo
uważać, ponieważ niekiedy wynikanie jest pozorne.

Firma

Osoba

Komputer

zatrudnia

jest_przydzielony

Wszystkie  asocjacje  są  tu
niezbędne.  Asocjacji  zatrudnia
nie  można  wydedukować  z
dwóch  pozostałych,  ponieważ
są  pracownicy,  którym  nie
przydzielono komputera.

0..1

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

Czy masz prawidłowe asocjacje? (3)

  Asocjacje  Kwalifikowane:  Często,  pewien  atrybut  powiązany  z
asocjacją posiada  unikatowe znaczenie, pozwalając na jednoznaczny
podział zbioru obiektów (na pojedyncze obiekty lub grupy obiektów).
  Np.  kod_banku  identyfikuje  jednoznacznie  bank  w  ramach
konsorcjum banków. Warto oznaczyć taką sytuację.

  Liczność:  Staraj  się  wprowadzić  liczność  do  diagramów,  ale  nie
przywiązuj  do  tego  zbytniej  wagi  na  początku  analizy,  ponieważ
liczności  bardzo  często  ulegają  zmianie  w    miarę  rozwijania
projektu.

 Opuszczone asocjacje: Staraj się zidentyfikować je na podstawie
atrybutów (mogą z nich wynikać), na podstawie diagramów
dynamicznych lub scenariuszy interakcji aktorów z systemem.

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

Za mało lub za dużo asocjacji?

 Brak ścieżki dostępu do pewnych obiektów: Możemy to stwierdzić
próbując skonstruować zapytanie.

 Redundantna informacja w asocjacji: Zastanowić się, czy jest
potrzebna.

 Brak operacji, które wykorzystują daną asocjację: Jeżeli nie
mamy operacji lub zapytań, które efektywnie używają danej asocjacji,
wówczas prawdopodobnie jest ona zbędna.

W  praktyce,  rzadko  udaje  się  wypracować  dostatecznie
rygorystyczne reguły postępowania, kóre prowadziłyby skutecznie
do celu, czyli do uzyskania modelu o zadawalającej jakości. Liczba
sytuacji,  z  którymi  mają  do  czynienia  analitycy,  jest  ogromna  i
zawsze będą istnieć przypadki, kiedy omówione powyżej zalecenia
nie wystarczą. Ostatecznym kryterium jest więc próba uniknięcia
wszelkich  niespójności  i  uzyskania  pełnego  zadowolenia  klienta.
Dla wielu projektów jest to i tak bardzo trudne do osiągnięcia.

Model może zawierać zbyt mało lub zbyt dużo asocjacji, gdy:

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

Kryteria jakości modeli

 poprawny,
 kompletny,
 minimalny,
 czytelny,
 samo-tłumaczący się,
 podatny na modyfikacje.

Jednoczesne spełnienie wszystkich warunków jest często
niemożliwe, nie mniej jednak należy do tego dążyć.

Dobrej jakości model powinien być:

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

Poprawność

Poprawność syntaktyczna:

 Pojęcia są prawidłowo zapisane/narysowane/powiązane na

diagramie.

Poprawność semantyczna:

 Diagram odpowiada sytuacji z modelowanej rzeczywistości.

Najczęstsze błędy:

 użycie atrybutu zamiast klasy czy asocjacji lub odwrotnie,
 pominięcie uogólnienia lub specjalizacji,
 nieprawidłowa arność asocjacji (np. binarna zamiast n-narnej),
 użycie klasy zamiast asocjacji lub odwrotnie,
 pominięcie atrybutów w asocjacjach,
 pominięcie lub nieprawidłowa liczność asocjacji.

Poprawność syntaktyczna:

 Pojęcia są prawidłowo zapisane/narysowane/powiązane na

diagramie.

Poprawność semantyczna:

 Diagram odpowiada sytuacji z modelowanej rzeczywistości.

Najczęstsze błędy:

Model/diagram jest poprawny jeżeli wszystkie występujące na nim

pojęcia zostały właściwie użyte.

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

Kompletność

Jak to sprawdzić ?

 dokładnie, szczegółowo przejrzeć specyfikacje wymagań

dotyczących opisywanego fragmentu dziedziny problemowej

i sprawdzić czy są one wyrażone na diagramie,

 przejrzeć pojęcia zobrazowane na diagramie i porównać ich

opisy w wymaganiach,

 próbować porównywać ze sobą diagram klas i diagramy

dynamiczne sprawdzając ich zgodność i spójność.

Jak to sprawdzić ?

 dokładnie, szczegółowo przejrzeć specyfikacje wymagań

dotyczących opisywanego fragmentu dziedziny problemowej

i sprawdzić czy są one wyrażone na diagramie,

 przejrzeć pojęcia zobrazowane na diagramie i porównać ich

opisy w wymaganiach,

 próbować porównywać ze sobą diagram klas i diagramy

dynamiczne sprawdzając ich zgodność i spójność.

Model/diagram jest kompletny jeżeli wszystkie cechy opisywanego

obszaru są na nim wyrażone.

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

Minimalność

Model/diagram jest minimalny jeżeli każdy z aspektów wymagań

analizowanego obszaru występuje na schemacie tylko raz. Usunięcie

dowolnego elementu z diagramu minimalnego powoduje utratę informacji.

Model/diagram jest minimalny jeżeli każdy z aspektów wymagań

analizowanego obszaru występuje na schemacie tylko raz. Usunięcie

dowolnego elementu z diagramu minimalnego powoduje utratę informacji.

Atrybuty: Liczba_prac (liczba pracowników w projekcie)

i Kierownik dublują informację zawartą w asocjacjach.

PRACOWNIK

Imię

Nazwisko

Data_ur

PROJEKT

ID_projektu

Kierownik

Liczba_prac

pracuje_nad

kieruje

PRACOWNIK

Imię

Nazwisko

Data_ur

PROJEKT

ID_projektu

pracuje_nad

kieruje

0..1

Redundancja informacji jest czasami korzystna. Należy wtedy

udokumentować, które elementy są pochodnymi innych i w jaki sposób

się je wylicza lub wyprowadza.

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

Czytelność

B-D

B-C

B-E

A-C

A-E

A-D

D-B

C-B

E-B

A-C

A-E

A-D

Model/diagram jest czytelny jeżeli graficzna reprezentacja zawiera

minimum punktów percepcji (przecięć, załamań linii, itp.).

Kryteria czytelności: elementy w punktach rastru, ta sama wielkość

elementów, linie diagramu biegnące poziomo i/lub pionowo, minimalna

liczba przecięć czy załamań linii, symetria, itp.

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

Samo-tłumaczenie (1)

PROFESOR

SEMINARIUM

prowadzi

WYKŁAD

ASYSTENT

prowadzi

oferuje

objaśnia

NAUCZYCIEL

ZAJĘCIA

PROFESOR

ASYSTENT

SEMINARIUM

WYKŁAD

prowadzi

Model/diagram jest samo-tłumaczący się (samo-opisowy) jeżeli

wymagania analizowanego obszaru są reprezentowane na schemacie w

naturalny sposób, są zrozumiałe i na tyle wyczerpujące, że nie wymagają

dodatkowych wyjaśnień.

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

Samo-tłumaczenie (2)

Model/diagram jest samo-tłumaczący się także w sytuacji, gdy nie istnieje

potrzeba stosowania innych formalizmów (np. opisów słownych), dodatkowych

w stosunku do notacji pojęciowych modelu danych, w celu reprezentowania

cech analizowanego obszaru.

Model/diagram jest samo-tłumaczący się także w sytuacji, gdy nie istnieje

potrzeba stosowania innych formalizmów (np. opisów słownych), dodatkowych

w stosunku do notacji pojęciowych modelu danych, w celu reprezentowania

cech analizowanego obszaru.

PACJENT

LEKARZ

Opieka
Rodzaj_opieki

PACJENT

LEKARZ

jest_prowadzony

jest_konsultowany

0..1

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

Proponowana miara dla oceny

diagramu klas (1)

Przedmiot oceny cząstkowej

Ocena

1. Poprawność (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
(także w sytuacji odwrotnej), za wprowadzenie do diagramu aktora
systemu (?), za błędną nazwę klasy (z reguły rzeczownik w liczbie
pojedynczej)

0 - 3

1.2    poprawne:  identyfikacja  atrybutów  i  specyfikacja  ich  rodzaju
(opcjonalny,  powtarzalny,  pochodny,  klasowy);  odejmowanie
punktów  także  za  wprowadzenie  atrybutu  zamiast  asocjacji  (lub
odwrotnie) czy zbyt detaliczną specyfikację

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,  usuń,
czytaj,  pisz),  metody  zamiast  atrybutu  pochodnego,  metody
pochodnej (nie istnieje !), za zbyt detaliczną specyfikację

0 - 3

1.4 poprawne: identyfikacja struktur i rodzaju dziedziczenia
(rozłączne,

nierozłączne,

kompletne,

niekompletne,

jednoaspektowe,

wieloaspektowe,

jednokrotne,

wielokrotne,

dynamiczne) oraz rozmieszczenie atrybutów i metod w ramach
jednej hierarchii; odejmowanie punktów za np.: brak hierarchii,
nieprawidłową organizację hierarchii (np. klasy o różnej semantyce
w jednej hierarchii, zamiana ról podklas-nadklasa, obecność pętli w
strukturze, brak oznaczenia dla klasy abstrakcyjnej,

0 - 3

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

Proponowana miara dla oceny

diagramu klas (2)

Przedmiot oceny cząstkowej

Ocena

1.5

poprawna

identyfikacja

asocjacji:

właściwe

nazwy,

wykorzystywanie  ról,  poprawne  liczności,  obecność  atrybutów
asocjacji  (lub  klas  asocjacji);  odejmowanie  punktów  także  za
modelowanie  czynności  wykonywanych  poza  systemem  czy
interakcji aktora z systemem jako asocjacji, wprowadzanie asocjacji
redundantnych (na skutek nie uwzględnienia dziedziczenia asocjacji
czy

nieprawidłowego

oznaczenia

asocjacji

pochodnych),

wykorzystywanie elementów przynależnych 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 ograniczeń i komentarzy (ile i w jakiej postaci)

wykorzystywanie

tzw.

“obejść

ograniczeń

środowiska

implementacji” (np. asocjacja, agregacja czy kompozycja zamiast
dziedziczenia – akcje odpowiednie dla etapu projektowania, a nie
analizy)

0 - 3

2. Kompletność

0 - 3

3. Organizacja

0 - 5

Samo-tłumaczenie: czy nazwy dobrze przenoszą semantykę bytów

0 - 2

5. Minimalność

0 - 1

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

Proponowana miara dla oceny

diagramu klas (3)

Przedmiot oceny cząstkowej

Ocena

6. Nadmiarowość

0 - 1

7. Znajomość notacji języka modelowania

0 - 1

9. Ocena łączna

0 - 34

8. Czytelność

0 - 1

Document Outline