пропозиції роботи
Michał Piotrowski Java Programmer
Temat: ICONIX
Hej,nie wiem czy tak naprawdę jest to dobra grupa (możliwe, że dotyczy bardziej UMLa, a także programowania jako takiego), ale spróbujmy.
Ostatnio wpadło mi w łapki takie coś jak ICONIX - podoba mi się to podejście, gdyż istniejące narzędzia (Eclipse,EA,Junit i jego integracja z Mavenem/Springiem/niepotrzebne skreślić) działa naprawdę bardzo fajnie i od samego początku jako programista 'czuję moc' w tym rozwiązaniu.
Natknąłem się jednak na pewien problem przy tworzeniu diagramu sekwencji na podstawie 'robustness diagram' - przykład mamy choćby w PDFie http://community.sparxsystems.com/system/files/tutoria... na stronie 10. Mamy tam diagram, w którym coś, co wg. notacji ICONIX jest encją (MasterAccountList) i przesyłany jest do niej komunikat (ergo - wywoływana na niej metoda) -> findAccount().
W związku z tym mam pytanie jak w tym modelu projektowania/programowania traktować coś co w ICONIXie jest encją? Zakładałem, że punktem wejścia (kółko z kreską po lewej) jest to, co w programowaniu zwykło nazywać się kontrolerem (servlet, klasa kontrolera ze springa). Kontrolery ICONIXa to wykonanie jakiejś akcji (i obiekt tutaj na etapie diagramów jest mniej istotny). Zaś encję uważałem już za końcowy element - czyli po prostu fizyczny BEAN z danymi dla przykładu (czy kolekcję takowych).
Tymczasem na ww. rysunku wygląda to troszkę inaczej i chciałbym się dowiedzieć czy dobrze rozumuję, czy nie bardzo. Na diagramach to i może wygląda, ale potem trzeba pisać testy/klasy i dobrze wiedzieć czy tworzone obiekty to np: AccountManagerService czy AccountManagerBean (rozróżnienie funkcjonalności po nazwach mam nadzieję jest zrozumiałe i czytelne).
Z góry dziękuję za poradę,
MichałMichał Piotrowski edytował(a) ten post dnia 06.12.11 o godzinie 17:02
