Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.

Podobne prezentacje


Prezentacja na temat: "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."— Zapis prezentacji:

1 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

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

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

4 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

5 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 ABAB A1 A2 B1 B2 UZUPEŁNIENIE O METODY

6 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

7 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 ZAGRANICAMIASTO W KRAJU WOJEWÓDZTWO znajduje się w

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

9 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ĘŻCZYZNAKOBIETA ZAGRANICA MIASTO W KRAJU OSOBA MIEJSCE związana z MIASTO W KRAJU WOJEWÓDZTWO znajduje się w

10 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 rozprzestrzenianiu, 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.

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

12 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,...

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

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

15 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. E K1 E K2 E K1 E K2 K K1 K2 K K1 K2 {overlapping}

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

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

18 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 { }, ( … ) 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.

19 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

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

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

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

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

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

25 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

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

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

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

29 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. 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ć:

30 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: 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. Model/diagram jest poprawny jeżeli wszystkie występujące na nim pojęcia zostały właściwie użyte.

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

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

33 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 33 Czytelność 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 E D A 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.

34 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 SEMINARIUMWYKŁ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ń.

35 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. PACJENT LEKARZ Opieka Rodzaj_opieki * * PACJENT LEKARZ jest_prowadzony jest_konsultowany * * * 0..1

36 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 36 Proponowana miara dla oceny diagramu klas (1) Przedmiot oceny cząstkowejOcena 1. Poprawność (suma ocen z punktów ) 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) 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ę 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ę 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

37 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 37 Proponowana miara dla oceny diagramu klas (2) Przedmiot oceny cząstkowejOcena 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) identyfikacja agregacji, kompozycji i asocjacji kwalifikowanej 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) Kompletność Organizacja Samo-tłumaczenie: czy nazwy dobrze przenoszą semantykę bytów Minimalność0 - 1

38 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 38 Proponowana miara dla oceny diagramu klas (3) Przedmiot oceny cząstkowejOcena 6. Nadmiarowość Znajomość notacji języka modelowania Ocena łączna Czytelność 0 - 1


Pobierz ppt "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 12, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."

Podobne prezentacje


Reklamy Google