Upload
hans
View
24
Download
2
Embed Size (px)
DESCRIPTION
Projektowanie systemów informacyjnych. Wykład 13. Strategie rozwijania systemu. Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. - PowerPoint PPT Presentation
Citation preview
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 1K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 1
Projektowanie systemów informacyjnych
Kazimierz Subieta, Ewa Stemposz
Instytut Podstaw Informatyki PAN, Warszawa
Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa
Wykład 13
Strategie rozwijania systemu
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 2
Zagadnienia
Strategie rozwijania systemu: top-down bottom-up inside-outCykle życiowe systemu informatycznegoAnaliza - kolejne krokiKryteria jakości modeli
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 3
Budowa modelu obiektowego; strategia top-down
Kolejnerozwinięcia sącoraz bardziej
szczegółowe
Od ogółu do szczegółu (top-down) - najpierw definiuje się ogólne pojęcia, a następnie rozwija się je poprzez dodawanie szczegółów stosując elementy podstawowe (prymitywy).
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 4
Strategia top-down; prymitywy (1)
KLASY => KLASY POWIĄZANE
KLASA => SPECJALIZACJE
KLASA=> KILKA KLAS NIEZALEŻNYCH
POWIĄZANIE=> POWIĄZANIE RÓWNOLEGŁE
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 5
Strategia top-down; prymitywy (2)
POWIĄZANIE=> KLASA Z POWIĄZANIAMI
UZUPEŁNIENIE O ATRYBUTY PROSTE
ROZWINIĘCIE ATRYBUTÓW AB
A1A2B1B2
UZUPEŁNIENIE O OPERACJE
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 6
Strategia top-down; przykłady (1)
UMYSŁOWY
PRACOWNIK
FIZYCZNY
PRACOWNIK
NAGRODA NAGRODANOBLA
NAGRODAOSCARA
MIEJSCE
WOJEWÓDZTWO
MIASTO
*
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 7
Strategia top-down; przykłady (2)
MĘŻCZYZNA
mieszka w
urodziła się w
MIEJSCEOSOBA
DANEDEMOGRAFICZNE
DANE OMIESZKAŃCACH
DANE OTERENIE
KOBIETA ZAGRANICA MIASTO W KRAJU
WOJEWÓDZTWO
znajduje się w
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 8
Budowa modelu obiektowego; strategia bottom-up
Od szczegółu do ogółu (bottom-up) - najpierw definiuje się pojęcia elementarne, a następniebuduje się z nich struktury w celu stworzenia pojęć ogólnych.
Od szczegółu do ogółu (bottom-up) - najpierw definiuje się pojęcia elementarne, a następniebuduje się z nich struktury w celu stworzenia pojęć ogólnych.
WYMAGANIA
WYMAGANIA nWYMAGANIA 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ŃCOWYDIAGRAM
ZINTEGROWANY
. . . . .
. . . . .
.....
..........
.....
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 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 MIEJSCEzwiązana z
MIASTO W KRAJU
WOJEWÓDZTWO
znajduje się w
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 10
Strategia inside-out
Rozprzestrzenianie (inside-out) - najpierw definiuje się pojęcia, które wydają sie być najważniejsze, a następnie rozwija się je poprzez dobudowywanie kolejnych pojęć, którestanowią ich uzupełnienie.
Rozprzestrzenianie (inside-out) - najpierw definiuje się pojęcia, które wydają sie być najważniejsze, a następnie rozwija się je poprzez dobudowywanie kolejnych pojęć, którestanowią ich uzupełnienie.
POJĘCIANAJWAŻNIEJSZE
DIAGRAMY(coraz szersze)
WYMAGANIA
DIAGRAMKOŃCOWY
Diagram wstępny
Diagramy pośrednie
W istocie, strategie projektowania są zwykle oparte na rozprzestrzenianiu, z inklinacją do top-down lub bottom-up.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 11
Cykle życia systemu informatycznego (1)
Model wodospadowy
Zbieranie i analiza
wymagań
Wstępneprojektowanie
Szczegółoweprojektowanie
Implementacja
Testowanieskładowych
Integracja
Testowaniesystemu
Utrzymanie
Następna faza zaczyna się po zakończeniu poprzedniej.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 12
Cykle życia systemu informatycznego (2)
Analiza
Integracja i testowanie systemu
Projektowanie
Implementacjai testowanieskładowych
Specyfikacja wymagań
Gotowawersja 1
Gotowawersja 2
Gotowawersja 3
Model spiralnyPowtarzanie się tych samych czynności w kolejnych fazach rozwoju projektu.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 13
Model z prototypowaniem
Zbieraniei analiza wymagań
Projektowanie
Budowaprototypu
Implementacja
Ocena jakościi testowanie
Utrzymanie
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 14
Analiza - kolejne kroki
Pierwszy przebieg: zidentyfikuj klasy i ich 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 rafinacji asocjacji: wprowadź oznaczenia liczności asocjacji, dodaj atrybuty związane z asocjacjami, wyszukaj ewentualne relacje zawierania się (agregacje i kompozycje).
Udokumentuj to w modelu obiektowym i słowniku danych.
Czwarty przebieg: dodaj operacje/metody do klas poprzez zbudowanie modeludynamicznego. 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.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 15
Zidentyfikuj potencjalne klasy
transakcje: pożyczka, spotkanie, sprzedaż,zdarzenia: lądowanie, zapytanie,role: matka, ojciec, nauczyciel, pasażer,rzeczy dotykalne: samochód, czujnik, składnik, samolot.
Zidentyfikuj kandydujące rzeczowniki - ze sformułowania problemu i specyfikacji wymagań na system - jako potencjalne klasy.
Szukaj transakcji, zdarzeń, ról i rzeczy dotykalnych, np.:
Zidentyfikuj potencjalne kolekcje (zbiory). Pewne rzeczowniki implikują kolekcje i mogą stać się kontenerami (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, linie komunikacyjne, urządzenia peryferyjne, obiekty wejścia/wyjścia,...
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 16
Zidentyfikuj potencjalne atrybuty
Rzeczownik może być atrybutem, jeżeli nie można przypisać mu 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 jako “właściciel”atrybutu.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 17
Dokumentuj swoje ustalenia!Utwórz zarys projekt w postaci modelu obiektowego wysokiego poziomu(najlepiej, przy użyciu narzędzia CASE).
Twórz nowy model obiektowy dla każdego kroku iteracyjnego. Staraj sięrównolegle budować model dynamiczny.
Pracuj nad słownikiem danych.
Ustal: Kategorię obiektów klasy (ludzie, miejsca, rzeczy, ...). Kto/co tworzy obiekty klasy. Kto/co usuwa obiekty klasy. Kto/co modyfikuje obiekty klasy. Kto/co posiada lub zawiera obiekty klasy.Wypisz interfejsy wspomagane przez klasę.Wypisz widoczne publicznie atrybuty.Wypisz źródło wartości dla każdego atrybutu w klasie.Wypisz asocjacje klasy z innymi klasami.Sformułuj cel istnienia tej klasy.Opisz tę klasę.
Dla każdej klasy:
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 18
Dodaj generalizacje/specjalizacjei usuń niepotrzebne klasy i atrybuty
Wyciągnij przed nawias wszelkie wspólne własności (operacje 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.
Podklasy mogą mieć puste lub niepuste przecięcia. Oznacz je odpowiednio.Obiekt, należący do przecięcia, dziedziczy z obu podklas.
EK1 EK2
EK1 EK2
K
K1
K2
K
K1
K2{overlapping}
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 19
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ę.
Wystąpienia asocjacji są dowolnymi 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 analizy modelu dynamicznego - rozwijaj więc tenmodel.
Udokumentuj te ustalenia w modelu obiektowym i w słowniku danych!
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 20
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.
Unikaj klas niejasnych. Klasy powinny być jednoznacznie określone. 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 będzie 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.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 21
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 ze sobą, np. przy pomocy nieformalnego opisu lub poprzez specjalnie przygotowany formularz.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 22
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 dwóch różnych pojęć,np. asocjacja Kierownik i atrybut Kierownik
Przykład słownika
Konto - pojedyncze konto w banku, w stosunku do którego wykonywane są bieżące transakcje. 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.
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 akceptowania kart klientów, pobierania i wypłacania gotówki klientom, pobierania gotówki z sejfów, wpłacania stanu kasy do sejfów........
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 23
Czy masz prawidłowe atrybuty? (1)
Zwykle atrybuty nie są wystarczająco dokładnie opisane w dziedzinie problemowej. Należy je określać także pośrednio: z wiedzy dziedzinowej, w oparciu o informacje wynikające z wymagań oraz z charakterystyk operacji zachodzących na obiektach.
Na szczęście, rzadko wpływają na podstawową strukturę modelu.
Obiekty. Jeżeli atrybut posiada niezależne znaczenie, wówczas jest obiektem - można tworzyć dla niego powiązania z innymi obiektami. Np. Adres jest raczej obiektem niż atrybutem, natomiast Nazwisko, Zarobek są atrybutami.
Identyfikatory. W zasadzie, model obiektowy zapewnia unikalną tożsamość obiektów, skąd wynika, że atrybuty będące identyfikatorami obiektów są zbedne; specyfikuje się tylko takie identyfikatory, które występują explicite w dziedzinie problemowej.
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 dla pracownika stał by się wtedy atrybutem asocjacji.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 24
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ą 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świetleniem).
Atrybuty rozszczepiające (dyskryminatory). Jeżeli atrybut ma charakter dzielącego ekstensję danej klasy na 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 powstają wskutek przedwczesnych decyzji implementacyjnych.
Atrybuty odnoszące się do implementacji. Należy je wyeliminować z modelu analizy. Przykładem są atrybuty, takie jak: format pliku graficznego ze zdjęciem pracownika, rozmiar obiektu w bajtach, przyjętą częstość składowania obiektu, itp.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 25
Co może sugerować, że brakuje pewnych klas?
Asymetria w asocjacjach i generalizacjach. Należy dodać nowe klasy poprzez analogię.
Rozłączne grupy atrybutów i operacji wewnatrz klasy. Należy rozdzielić taka klasę na kilka innych (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 - 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 sematyce i strukturze. 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: przestają mieć znaczenie stare atrybuty, a nabierają znaczenia nowe, takie jak np. waga metali, zdolność do recyclingu, itd.:
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 26
Czy masz prawidłowe asocjacje? (1) Asocjacje związane z likwidowaną klasą. Jeżeli klasa jest eliminowana z modelu, to wszystkie asocjacje z nią związane są również eliminowane. W takich sytuacjach należy rozpatrzyć, czy nie powinny być jednak przyłączone do innych klas.
Nierelewantne lub implementacyjne asocjacje. Należy wyeliminować z modelu analizy te asocjacje, które nie odnoszą się do dziedziny problemowej.
Akcje jako asocjacje. 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ć usunięty. Jest to bardzo częsty błąd.
Asocjacje ternarne, 3-arne, itd. Większość z nich należy traktować bardzo podejrzliwie i starać się zdekomponować na asocjacje binarne poprzez wprowadzenie klasy pośredniczącej.
Klasa pośrednicząca
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 27
Czy masz prawidłowe asocjacje? (2)
posiada
Asocjacje ź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.
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
Asocjacje i ich liczności nie mogą być wydedukowane; wszystkie są tu niezbędne. Asocjacji zatrudnia nie można wydedukować z dwóch pozostałych, ponieważ mogą być pracownicy bez przydzielonego komputera.
*
**
0..1
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 28
Czy masz prawidłowe asocjacje? (3)
Kwalifikowane asocjacje. Często, pewien atrybut powiązany z asocjacją posiada unikatowe znaczenie, pozwalając na jednoznaczny podział ekstensji ( na pojedyncze obiekty lub grupy obiektów). 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. 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 z zewnętrzem systemu.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 29
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ą daną asocjację. Jeżeli nie mamy operacji lub zapytań, które efektywnie używają 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 przypadków i 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.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 30
Kryteria jakości modeli
kompletny, prawidłowy, minimalny, wyrazisty, czytelny, samo-tłumaczący się, podatny na modyfikacje.
kompletny, prawidłowy, minimalny, wyrazisty, czytelny, samo-tłumaczący się, podatny na modyfikacje.
Jednoczesne spełnienie wszystkich warunków jest często niemożliwe,ale należy do tego dążyć.
Dobrej jakości model powinien być:
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 31
Kompletność
Jak to sprawdzić ?
dokładnie, szczegółowo przejrzeć specyfikacje wymagań dotyczących 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ó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 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ównywać ze sobą diagram klas i diagramy dynamiczne sprawdzając ich zgodność i spójność.
Model/diagram jest KOMPLETNY jeżeli wszystkie cechy opisywanegoobszaru są na nim wyrażone.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 32
Prawidłowość
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 atrybutów w asocjacjach, pominięcie lub nieprawidłowa liczność asocjacji.
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 atrybutów w asocjacjach, pominięcie lub nieprawidłowa liczność asocjacji.
Model/diagram jest PRAWIDŁOWY jeżeli wszystkie występujące na nimpojęcia zostały właściwie użyte.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 33
Minimalność
Model/diagram jest MINIMALNY jeżeli każdy z aspektów wymagańanalizowanego obszaru występuje na schemacie tylko raz. Usunięcie dowolnegoelementu 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 dowolnegoelementu z diagramu minimalnego powoduje utratę informacji.
Liczba_prac jest liczbą pracowników w projekcie.Atrybut Kierownik dubluje informację zawartą w asocjacji.
PRACOWNIKImię
NazwiskoData_ur
PROJEKTID_projektuKierownik
Liczba_prac
pracuje_nad kieruje
PRACOWNIKImię
NazwiskoData_ur
PROJEKTID_projektu
pracuje_nad kieruje0..1
* *
0..1
Redundancja informacji jest czasami korzystna. Należy wtedy udokumentować, które elementysą pochodnymi innych i w jaki sposób się je wylicza lub wyprowadza.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 34
Wyrazistość
PROFESOR SEMINARIUM
prowadzi
WYKŁADASYSTENT
organizuje
oferuje
objaśnia
NAUCZYCIEL ZAJĘCIA
PROFESOR ASYSTENT SEMINARIUM WYKŁAD
prowadzi
Model/diagram jest WYRAZISTY jeżeli wymagania analizowanego obszaru sąreprezentowane na schemacie w naturalny sposób, są zrozumiałe i na tylewyczerpujące, że nie wymagają dodatkowych wyjaśnień.
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 35
Czytelność
Kryteria estetyczne: elementy w punktach rastru, ta sama wielkość elementów, liniediagramu biegnące poziomo i/lub pionowo, minimalna liczba przecięć lini, symetria, itp.
Kryteria estetyczne: elementy w punktach rastru, ta sama wielkość elementów, liniediagramu biegnące poziomo i/lub pionowo, minimalna liczba przecięć lini, symetria, itp.
B
B-D
B-C
B-E
A-C
A-E
C
E
D
A
A-D
B
D-B
C-B E-B
A-CA-E
C ED
A
A-D
Model/diagram jest CZYTELNY jeżeli graficzna reprezentacja zawiera minimum punktów percepcji (przecięć, załamań linii, itp.).
K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 13, Folia 36
Model samo-tłumaczącyModel/diagram jest SAMO-TŁUMACZĄCY SIĘ jeżeli nie istnieje potrzebastosowania innych formalizmów (np. opisów słownych), dodatkowych wstosunku do notacji pojęciowych modelu danych, w celu reprezentowania cechanalizowanego obszaru.
Model/diagram jest SAMO-TŁUMACZĄCY SIĘ jeżeli nie istnieje potrzebastosowania innych formalizmów (np. opisów słownych), dodatkowych wstosunku do notacji pojęciowych modelu danych, w celu reprezentowania cechanalizowanego obszaru.
PACJENT
LEKARZ
OpiekaTyp_lekarza
*
*
PACJENT
LEKARZ
jest_prowadzony
jest_konsultowany
* *
*0..1