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


===== Do przeczytania =====

  -[[http://home.agh.edu.pl/~pszwed/pub/uml/uml-pszwed-klasy.pdf|Wykład - diagram struktury klas]]
  -[[http://home.agh.edu.pl/~pszwed/pub/uml/refman.pdf|UML Reference Manual (1.0)]]
  -[[http://home.agh.edu.pl/~pszwed/pub/uml/omguml.pdf|Specyfikacja OMG  UML]]
  -[[http://home.agh.edu.pl/~pszwed/pub/uml/Antywzorce.pdf|Antywzorce w stosowaniu UML]]
  - Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski: UML 2.0 w modelowaniu systemów informatycznych, Helion  

===== Identyfikacja klas =====

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

===== Identyfikacja atrybutów ===== 

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** 


===== Związki =====

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

  -zależność (zazwyczaj zależność kodu)
  -dziedziczenie
  -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:

|dziedziczenie|jest|Student jest Osobą|
|asocjacja|odnosi się do, dotyczy, ma informacje o, używa, korzysta z|Recenzja odnosi się do Filmu, Kierowca używa Samochodu, Ocena z Przedmiotu= Ocena dotyczy Przedmiotu|
|agregacja|ma|Pokój ma Ściany|
|kompozycja|składa się|Mieszkanie składa się z  Pokoi, Kuchni, Łazienki, WC|

 

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


=====Identyfikacja metod (w tym zadaniu opcjonalnie) =====

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.