Projektowanie systemów informacyjnych

K.Subieta. Projektowanie systemów informacyjnych, Wykład 10, Folia 1

Projektowanie systemów informacyjnych

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

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

Wykład 10: OMT - Strategia rozwijania systemu (2)


Warunki zapewnienia Jakości Modeli

• KOMPLETNOŚĆ• PRAWIDŁOWOŚĆ• MINIMALNOŚĆ• PEŁNIA WYRAZU• CZYTELNOŚĆ• SAMO-TŁUMACZENIE SIĘ• PODATNOŚĆ NA MODYFIKACJĘ

• KOMPLETNOŚĆ• PRAWIDŁOWOŚĆ• MINIMALNOŚĆ• PEŁNIA WYRAZU• CZYTELNOŚĆ• SAMO-TŁUMACZENIE SIĘ• PODATNOŚĆ NA MODYFIKACJĘ

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


Kompletność

Model/diagram jest KOMPLETNY jeżeli wszystkie cechy opisywanego obszaru są na nim wyrażone.

Jak to sprawdzić ?

• przejrzeć w szczegółach wszystkie wymagania odnośnie opisywanego obszaru i sprawdzić czy są one wyrażone na diagramie

• przejrzeć pojęcia zobrazowane na diagramie i sprawdzić ich opisy w wymaganiach

• próbować porównać ze sobą diagram danych, diagramy dynamiczne i ewentualnie diagramy funkcjonalne, sprawdzając ich zgodność i spójność

Model/diagram jest KOMPLETNY jeżeli wszystkie cechy opisywanego obszaru są na nim wyrażone.

Jak to sprawdzić ?

• przejrzeć w szczegółach wszystkie wymagania odnośnie opisywanego obszaru i sprawdzić czy są one wyrażone na diagramie

• przejrzeć pojęcia zobrazowane na diagramie i sprawdzić ich opisy w wymaganiach

• próbować porównać ze sobą diagram danych, diagramy dynamiczne i ewentualnie diagramy funkcjonalne, sprawdzając ich zgodność i spójność


PrawidłowośćModel/diagram jest PRAWIDŁOWY jeżeli wszystkie występujące na

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

Prawidłowość syntaktyczna (składniowa)

• pojęcia są prawidłowo zapisane/narysowane/powiązane na diagramie

Prawidłowość semantyczna• diagram odpowiada sytuacji z modelowanej rzeczywistości

Częste błędy semantyczne:– użycie atrybutu zamiast klasy lub odwrotnie– pominięcie uogólnienia lub specjalizacji– nieprawidłowa arność asocjacji (np. binarna zamiast n-narna)– użycie klasy zamiast asocjacji lub odwrotnie– pominięcie kluczy w klasach– pominięcie atrybutów w asocjacjach– pominięcie lub nieprawidłowa liczność asocjacji

Model/diagram jest PRAWIDŁOWY jeżeli wszystkie występujące na nim pojęcia zostały użyte właściwie.

Prawidłowość syntaktyczna (składniowa)

• pojęcia są prawidłowo zapisane/narysowane/powiązane na diagramie

Prawidłowość semantyczna• diagram odpowiada sytuacji z modelowanej rzeczywistości

Częste błędy semantyczne:– użycie atrybutu zamiast klasy lub odwrotnie– pominięcie uogólnienia lub specjalizacji– nieprawidłowa arność asocjacji (np. binarna zamiast n-narna)– użycie klasy zamiast asocjacji lub odwrotnie– pominięcie kluczy w klasach– pominięcie atrybutów w asocjacjach– pominięcie lub nieprawidłowa liczność asocjacji


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.

Redundancja informacji jest czasami korzystna. Należy wtedy udokumentować, które elementy są pochodnymi innych i w jaki sposób je się wylicza lub wyprowadza

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.

Redundancja informacji jest czasami korzystna. Należy wtedy udokumentować, które elementy są pochodnymi innych i w jaki sposób je się wylicza lub wyprowadza

Liczba_prac jest liczbą pracowników w projekcieAtrybut Kierownik dubluje informację zawartą w asocjacji

PRACOWNIKImię

NazwiskoData_ur

PROJEKTID_projektuKierownik

Liczba_prac

Pracuje_nad Kieruje

PRACOWNIKImię

NazwiskoData_ur

PROJEKTID_projektu

Pracuje_nad Kieruje


Pełnia WyrazuDiagram jest WYRAZISTY 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ń.

Diagram jest WYRAZISTY 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ń.

PROFESOR SEMINARIUM

Prowadzi

WYKŁADASYSTENT

Organizuje

Oferuje

Objaśnia

NAUCZYCIEL ZAJĘCIA

PROFESOR ASYSTENT SEMINARIUM WYKŁAD

Prowadzi


CzytelnośćDiagram jest CZYTELNY jeżeli graficzna reprezentacja zawiera minimum punktów

percepcji (przecięć, załamań linii, itp.). Kryteria estetyczne: elementy w punktach rastru, ta sama wielkość elementów, linie

diagramu biegnące poziomo i/lub pionowo, minimalna liczba przecięć lini, symetria, itp.

Diagram jest CZYTELNY jeżeli graficzna reprezentacja zawiera minimum punktów percepcji (przecięć, załamań linii, itp.).

Kryteria estetyczne: elementy w punktach rastru, ta sama wielkość elementów, linie diagramu biegnące poziomo i/lub pionowo, minimalna liczba przecięć lini, symetria, itp.

BB-D

B-C

B-EA-C

A-E

C

E

D

A

A-D

B

B-D

B-C B-E

A-CA-E

C ED

A

A-D


Model samo-tłumaczącyModel/diagram jest SAMO-TŁUMACZĄCY SIĘ jeżeli nie istnieje potrzeba stosowania

innych formalizmów (np. opisów słownych), dodatkowych w stosunku do notacji pojęciowych modelu danych, w celu reprezentacji cech analizowanego obszaru.

Model/diagram jest SAMO-TŁUMACZĄCY SIĘ jeżeli nie istnieje potrzeba stosowania innych formalizmów (np. opisów słownych), dodatkowych w stosunku do notacji pojęciowych modelu danych, w celu reprezentacji cech analizowanego obszaru.

PACJENT

LEKARZ

PACJENT

LEKARZ

OpiekaTyp_lekarza Jest_prowadzony

Jest_konsultowany


Czy masz prawidłowe klasy? (1)

Unikaj klas nadmiarowych. 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; druga jest bardziej informatywna.

Unikaj klas nierelewantnych. Jeżeli klasa ma niewielki związek z problemem, wówczas powinna być pominięta, szczególnie na wyższych poziomach abstrakcji. Np. w systemie dla teatru zawód widza jest nieistotny, natomiast jest istotny dla pracownika teatru.

Unikaj klas niejasnych. Klasy powinny mieć jednoznacznie okreslone. Np. klasa Podmiot_obsługi może być rozumiana jak Klient, Bank, Pasażer, Firma, itd.

Atrybuty. Muszą być jednoznacznie przypisane do klas i charakteryzować indywidualne obiekty. Jeżeli atrybut może istnieć niezależnie od obiektu, być może lepiej zrobić z niego klasę. Np. atrybut Dzieci_pracownika dla klasy Pracownik.

Operacje. Również muszą być przypisane do klas i działać na indywidualnych obiektach lub zbiorach obiektów. W niektórych sytacjach operacja okazuje 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.


Czy masz prawidłowe klasy? (2)

Role. Nazwa klasy powinna wyrażać jej istotny charakter, a nie rolę jaką pełni w związku z pewną asocjacją. 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 dana osoba w asocjacji z samochodem. Ta osoba może być połączona w 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 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, drugi ze świata jego wnętrza, oraz powiązać te dwa diagramy przy pomocy nieformalnego opisu lub poprzez specjalnie przygotowany formularz.


Przygotowanie słownika

Bardzo istotny element każedego projektu. Pojedyncze słowa używane w modelach mogą mieć bardzo różne interpretacje, mimo pozornej zgodności. Należy dążyć do maksymalnego uproszczenia, ujednolicenia i 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 dwióch różnych pojęć,np. asocjacja Kierownik i atrybut Kierownik

Przykład słownika

Konto - pojedyncze konto w banku w stosunku do któego wykonywane są bieżące transakcje. Konta mogą być różnych typów, w szczególności konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto.

Bank - instytucja finansowa zarządzająca pieniędzmi i kontami klientów, wydająca karty bankowe, udzielająca kredytów i prowadząca inne operacje finansowe.

Klient - pojedyncza osoba, osoba prawna, małżeństwo, firma, instytucja.

Kasjer - pracownik banku posiadający uprawnienia do wejścia do kabiny kasowej, akceptowania kart klientów, pobierania i wypłacania gotówki klientom, pobierania gotówki z sejfów, wpłacania stanu kasy do sejfów........


Czy masz prawidłowe asocjacje? (1)Asocjacje pomiędzy likwidowaną klasą. Jeżeli klasa jest eliminowana z modelu, to wszystkie asocjacje związane z tą klasą są również eliminowane. Należy w takich sytuacjach rozpatrzyć, czy nie powinny być one przyłączone do innych klas.

Nierelewantne lub implementacyjne asocjacje. Należy wyeliminować z modelu te asocjacje, które nie odnoszą się do dziedziny problemowej.

Akcje. Asocjacje powinny opisywać strukturalne własności dziedziny problemowej, a nie aspekt jej działania. Np. weryfikacja_klienta opisuje interakcję pomiędzy obiektem Kasjer i obiektem Klient, a nie związek pomiędzy tymi obiektami. Taki związek strukturalny nie ma jednoznacznej interpretacji w dziedzinie problemowej, wobec czego powinien być usuniety.Jest to bardzo częsty błąd.

Asocjacje ternarne, 4-arne, itd. Większość z nich nalezy traktować bardzo podejrzliwie i starać się zdekomponować na asocjacje binarne poprzez wprowadzenie klasy pośredniczącej.

Klasa pośrednicząca


Czy masz prawidłowe asocjacje? (2)

Asocjacje pochodne. 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 uważać, ponieważ niekiedy wynikanie jest pozorne.

Firma Osoba

Komputer

zatrudnia

ma_przydzielony

posiada

Asocjacje i ich liczności nie mogą być wydedukowane; wszystkie są niezbędne. Asocjacji zatrudnia nie można wydedukować z dwóch pozostałych, ponieważ mogą być pracownicy bez przydzielonego komputera.

Asocjace źle nazwane. Na ogół należy unikać nazw sugerujących czynności lub procesy. Np. pomiędzy bankiem a klientem: nie zarządza_kontem, a raczej trzyma_konto.

Dodać nazwy ról kiedy jest to właściwe. Np. pomiędzy firmą i osobą dla asocjacji pracuje_dla warto dodać role pracodawca i pracownik, aby uniknąć wątpliwości kto dla kogo pracuje.


Czy masz prawidłowe asocjacje? (3)

Kwalifikowane asocjacje. Często, pewien atrybut jest powiazany z asocjacją pozwalając na zredukowanie jej liczności. Np. kod_banku identyfikuje bank w ramach konsorcjum banków, w związku z czym asocjacje np. kart bankowych z bankiem można kwalifikować kodem banku.

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 z zewnetrzem systemu.


Czy masz prawidłowe atrybuty? (1)Zwykle atrybuty nie są w pełni opisane w dziedzinie problemowej. Należy je określać domyślnie zarówno z wymagań, wiedzy dziedzinowej, jak i charakterystyki operacji zachodzących na obiektach. Na szczęście, rzadko wpływają na podstawową strukturę modelu.

Obiekty. Jeżeli atrybut ma niezależne znaczenie, wówczas jest obiektem. Np. Adres jest raczej obiektem niz atrybutem, natomiast Nazwisko, Zarobek są atrybutami.

Kwalifikatory. Jeżeli wartość atrybutu zależy od kontekstu, to należy zidentyfikować ten kontekst i odpowiednio ulokować atrybut. Np. nr_pracownika może być atrybutem pracownika lub atrybutem związku pomiędzy pracownikiem i firmą, w zalezności od liczności tego związku.

Nazwy. Nazwy są często kwalifikatorami. Np. należy zapytać: Czy nazwa pozwala efektywnie wybrać element ze zbioru? Jeżeli nie, to jest to raczej nazwa klasy. Inne pytanie: Czy obiekt może mieć więcej niz jedną nazwę? Jeżeli tak, to jest to raczej atrybut asocjacji.

Identyfikatory. W zasadzie, model obiektowy zapewnia unikalną tożsamość obiektów, skąd wynika, że atrybuty będące identyfikatorami obiektów są zbedne.

Atrybuty asocjacji. Są zwykle oczywiste w przypadku asocjacji m:n. Dla asocjacji n:1 i 1:1 nie jest to oczywiste. Można stosować myślowy eksperyment: “Co by było jeżeli ta asocjacja byłaby m:n?” Np. atrybut zarobek dla pracownika stał by się wtedy atrybutem asocjacji.


Czy masz prawidłowe atrybuty? (2)

Atrybuty wewnętrzne. Jeżeli atrybut ma charakter wewnętrzny (jest niewidoczny) to należy go raczej wyeliminować z modelu. Np. dla metody oblicz_podatek mogą istniec wewnętrzne atrybuty przechowujące już obliczony podatek w kolejnych latach.

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

Atrybuty rozszczepiające. Jeżeli jakiś atrybut jest inny on pozostałych i ma charakter dzielący ekstensję klasy na rozłączne podklasy o różnej semantyce, to zastąp go specjalizacjami klas. Np. atrybut rodzaj_pracownika z wartościami: uczeń, stażysta, etatowy, na_zlecenie, emerytowany. Dość często takie atrybuty powstaja wskutek przedwczesnych decyzji implementacyjnych.

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


Co może sugerować, że brakuje pewnych obiektów?

Asymetria w asocjacjach i generalizacjach. Nalezy dodać nowe klasy poprzez analogię.

Rozdzielne grupy atrybutów i operacji wewnatrz klasy. Nalezy rozdzielić taka klasę na kilka.

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 konkretnego egzemplarza, z drugiej strony - operacje odnoszące sie do pozycji wydawniczej.

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

Zdublowane asocjacje o tej samej nazwie i przeznaczeniu. Sugerują, że warto utworzyć klasę bardziej ogólną.

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


Co może sugerować, że brakuje lub jest za dużo pewnych 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ą asocjację. Jeżeli nie mamy operacji lub zapytań, które efektywnie używają asocjacji, wówczas prawdopodobnie jest ona zbedna.

W praktyce, rzadko udaje się wypracować dostatecznie rygorystyczne reguły postępowania prowadzące do uzyskania jakościowego modelu. Liczba przypadków i sytuacji z którymi mają do czynienia projektanci jest ogromna i zawsze będą wynikać przypadki, kiedy omówione wyżej sugestie i kryteria zawiodą. Ostatecznym kryterium jest uniknięcie wszelkich niespójności i pełne zadowolenie klienta. Dla wielu projektów to kryterium jest bardzo trudne.

Projektowanie systemów informacyjnych

Documents

Transcript of Projektowanie systemów informacyjnych