Zadanie 1 Diagram struktury klas dziedziny

Tematem zadania jest modelowanie struktury klas dziedziny obejmujące:

• identyfikację klas
• identyfikację ich atrybutów
• ustalenie związków pomiędzy klasami
• identyfikację ich metod (niekoniecznie)

Wybieramy jeden z tematów do zamodelowania. W nawiasach podano przykładowe klasy…

• Biblioteka (Książka, Autor, Czasopismo, Artykuł, Egzemplarz, Wypożyczenie, Rezerwacja, Osoba, Czytelnik, Bibliotekarz)
• Dziekanat (Kierunek, Specjalność, Student, Grupa, Przedmiot, Zajęcia, Prowadzący, Ocena)
• Faktury (Towar, Kategoria, Klient, Sprzedawca, PozycjaFaktury, Cena)
• Restauracja (Menu, Potrawa, Kategoria, Stolik, Zamówienie, PozycjaZamówiania, Rachunek)
• Przychodnia (Lekarz, Specjalność, Pacjent, Dyżur, Wizyta, KartaPacjenta, Wpis, Skierowanie, Recepta)

1. Wykład - diagram struktury klas
2. UML Reference Manual (1.0)
3. Specyfikacja OMG UML
4. Antywzorce w stosowaniu UML
5. Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski: UML 2.0 w modelowaniu systemów informatycznych, Helion

• Celem zadania jest identyfikacja klas występujących w modelu dziedziny problemu.
• W zasadzie dobór klas powinien odpowiadać danym przechowywanym/przetwarzanym w systemie informatycznym.
• Model nie będzie uwzględniał klas, które mogą zostać wprowadzone podczas projektowania (np. okno dialogowe, skrypt PHP, strona HTML, baza danych, lista, wektor, itd.).
• Dodatkowo możliwe jest wprowadzenie klas abstrakcyjnych wykorzystywanych podczas określania związków generalizacji/dziedziczenia.

Wprowadzone atrybuty mają opisywać istotne z punktu widzenia zadań systemu cechy obiektów. Typowy przykład: skórzana tapicerka samochodu jest nieistotna dla systemu rejestracji pojazdów, natomiast może być istotna w systemie obsługującym komis samochodowy.

Uwaga. Nie należy dodawać atrybutów odpowiedzialnych za realizację asocjacji (klucze obce w ERD). Zamiast nich należy wprowadzić role

UML rozróżnia trzy grupy związków

1. zależność (zazwyczaj zależność kodu)
2. dziedziczenie
3. powiązania ( w tym asocjacja , agregacja i kompozycja)

W przypadku analizy dziedziny związek (1) raczej nie jest modelowany. Należy skupić się na związkach (2) i (3).

Dla przypomnienia: dobrym kryterium ustalania poszczególnych związków są frazy języka naturalnego:

Definiując powiązania należy koniecznie ustalić ich krotność. Np.: pokój ma 3,* ścian, mieszkanie składa się z 1,* pokoi.

W podejściu czysto obiektowym system jest siecią obiektów, które wysyłają do siebie komunikaty. Te komunikaty odpowiadają sygnaturom metod.

Sygnatura metody jest specyfikacją usługi, którą obiekt powinien zapewnić korzystając z informacji o swoim stanie (wartościach atrybutów i obiektach powiązanych) oraz obiektach zewnętrznych przekazanych jako parametry.

Identyfikując metody możemy posługiwać się rozmaitymi rutynowymi przepisami:

• Jeżeli obiekt lub aktor wysyła do innego obiektu jakieś dane lub sygnały, to zapewne odbiorca powinien zapewnić metodę, która pozwoli je odebrać
• Jeżeli mamy magazyn danych i funkcje, które pozwalają odczytać, zmodyfikować, usunąć lub dodać dane, to magazyn jest kandydatem na atrybut, natomiast funkcje/procesy kandydatami na metody pewnego obiektu.
• Obiekt nie może stworzyć lub usunąć sam siebie, natomiast może to zrobić kolekcja obiektów.
• Jeżeli mamy scenariusz przypadku użycia, to każda akcja zapewne stanie się metodą (użytkownik wprowadzając dane przesyła je do jakiegoś obiektu i wywołuje metodę, system wysyłając dane skorzysta z metody jakiegoś obiektu)
• Definiując metody należy starać się abstrahować od uwarunkowań technicznych. Może się zdarzyć, że 5 metod zidentyfikowanych w analizie dziedziny zaimplementujemy jako jedną sterowaną parametrem, który będzie przybierał 5 wartości – na przykład wykorzystując konstrukcje IF lub SWITCH-CASE.

Przykład: jeżeli piszemy system obsługi dziekanatu złą metodą jest przetwórzKwerendę() – w domyśle metoda bazy danych – natomiast dobrą: dodajStudenta(), usunStudenta(), zarejestrujStudenta() – w domyśle klasy GrupaStudentów Metoda przetwórzKwerendę() byłaby właściwa, gdybyśmy implementowali silnik bazy danych, a nie konkretny system wykorzystujący istniejące oprogramowanie do obsługi baz danych.