Witam,
Na zajęcia muszę zrobić diagram UML do poniższego zadania, zwracam się do was o jakąś radę / naprowadzenie / poprawienie, jeżeli coś źle robię. Ogólnie mam wykorzystać kompozycję oraz dziedziczenie, diagram ma być zbudowany z obiektów (wyodrębnienie klas itp.). Chciałbym zrobić diagram jak najlepiej, gdyż pomoże mi to bardzo w tworzeniu tego programu.
Tresc zadania:
Jak ja to rozumiem:
Moją główną klasą / obiektem będzie "COKP" (Centrum Obsługi Kart Płatniczych). COKP będzie posiadało / przechowywało listy obiektów Klient(firma) oraz Bank. Klient oraz Bank będą powiązane kompozycją z COKP. Następnie klasa Bank będzie powiązana kompozycją z klasą Karta, z klasy Karta będą dziedziczyły trzy mniejsze obiekty: Kredytowa, Debatowa oraz Bankomatowa. Ponadto Klient będzie powiązany kompozycją z klasą Bank. Czy wstępny zaras jest poprawny, chodzi mi o same wyodrębnienie klas i ich hierarchię.
Wstępny schemat (bez żadnych pól oraz metod), myślę taki zrobić, oczywiście to tylko zarys. Będzie to mój pierwszy diagram UML, za wszelkie rady wielkie dzięki.
Polecałbym Ci zastosowanie warstw.
To tak :
1 warstwa: klient (POSIADANIE KARTY)
2 warstwa: COKP (PROCES WERYFIKACJI KARTY I PŁATNOśCI)
3 warstwa: BANK (ODPOWIEDZ NA ŻĄDANIA COKP)
Karty leżą we wszystkich 3 warstwach.
Jakie interfejsy mają być dostępne z poziomu karty do BANKu, jakie dla KLIENTA, a jakie dla COKP?
Zależność banku od karty klienta, pod nadzorem cokp.
Podzieliłbym to w ten sposób, narysowanie UML, będzie bardziej transparentne. Ale to kwestia gustu, zależy jak na to popatrzysz.
Dla mnie ważny jest interfejs, który może być możliwie wspólny dla banków, oraz JEST wspólny dla poszczególnych kart. Oraz jednocześnie niezależny, dający łatwo się modyfikować.
COKP to warstwa "bezpieczeństwa", dbająca o ten proces i z jednej strony korzystająca z API banku, z drugiej zbierająca dane z karty.
Ale to kwestia gustu, jak sobie to wymyslisz.
@Wariad
Nie do końca zrozumiałem, o co chodzi z tymi interfejsami i jak zrobić proces weryfikacji? Pierwszy raz mam styczność z tak rozbudowanym projektem jak dla mnie ;/
Chodzi o cos takiego? Tak jakby karta jest własnością klienta zarządzaną przez BANK to oznacza, że karta dziedziczy z Klient i BANK posiada Klientów (kompozycja)?
Tego się tak nie robi, ale jak już napaliłeś się na takie wiązania (nie jest to dobra droga):
"Karta płatnicza" jest pewnym podtypem "debetówka", "kredytowa" ... - tutaj możesz zastosować dziedziczenie
Jakies tam cechy wspolne{
OSOBA PRYWATNA (DOKONUJACY PLATNOSCI / PROSZACY O STATUS PLATNOSCI)
FIRMA (DOKONUJACY PLATNOSCI / PROSZACY O STATUS PLATNOSCI)
}
Dalej masz Centrum, możesz użyć w kompozycji dwóch powyższych obiektów (dla kontkretnego przypadku) - 1 płatność - 1 objekt
Do tego możesz dołożyć połączenie pomiedzy obiektami bank<->COKP<->panel_platnosci<->(klient_platnik*); COKP<->Klient(firma) ...
*abstrakcja do testow
I teraz niech coś się w kartach zmieni to będzie lipa z poprawianiem, a jak będzie trzeba dodać coś do użytkowników to też będzie problem itd .., no ale kto co woli.
Teraz tak jeszcze raz spojrzałem na tematy jakie mam do wyboru i się zastanawiam czy nie prościej będzie mi napisać, któryś z tych dwóch:
Co o tym sądzicie? Jeżeli chodzi o diagram UML to chyba temat nr 1 jest prostszy i bardziej zrozumiały jak dla mnie, ktoś doradzi?
Nie ma prostszych i trudniejszych.
To wszystko zależy od Ciebie.
Jeżeli naprawdę chcesz dobrze to zrobić, to musisz prototypować, czyli tworzyć gotowe pół rozwiązanie. Dostrzeżesz wtedy pewne ograniczenia systemu. Rzadko kiedy uda się stworzyć system "uniwersalny".
Z tego co rysowałeś, Bank jest abstrakcyjny, posiadasz pewien interfejs do obsługi banku, lecz z poziomu COKP.
Wynika z tego, że bank nie istnieje jako obiekt sam w sobie, a jako ustawienia, dla konkretnego przypadku.
COKP łączy się z dwoma rodzajami klientów i daje im różne interfejsy.
Powinieneś rozbić COKP na mniejsze części. COKP to cały system, a Ty potrzebujesz konkretnych przypadków, tj. (1 płatność - 1 objekt){uzytkownik,odbiorca,karta} ; (komunikacja - żądanie){...} ; itd... .
Nie wiem jak mogę to inaczej ująć. Zastanów się jak działa system, na konretnym przypadku - zobaczysz jakie klasy powstaną Ci w efekcie tego procesu. Następnie dobrze byłoby zrobić symulację (protoyp + testy), tego systemu i zacząć ograniczać możliwości wpływania na niego z zewnątrz(czyli więcej szczegółów implementacyjnych). Dopisujesz te szczególiki to UML'a.
I teraz żyjesz w absrakcji, czyli robisz to na pół pewno (diagram UML - abstrakcyjny)
Albo tworzysz dla konkretnego rozwoju systemu (diagram UML - pewny)
Oczywiście mówię tutaj o prototypie.
Jak usiądziesz, a następnie będziesz się głowił jak to, jak tamto powinno wyglądać, po pierwsze stracisz masę czasu, po drugie system będzie niedopracowany, po trzecie nauczysz się najgorszego z możliwych nawyków wśród uwczesnych programistów.