Diagramy sekwencji są techniką, która idealnie nadaje się do zaprojektowania przepływu komunikatów pomiędzy klasami. Problem może powstać wtedy, gdy chcemy zaprezentować komunikację (użyte metody) na poziomie komponentów. Widziałem już w kilku miejscach diagramy sekwencji z komponentami. To bardzo niezdrowe rozwiązanie. Diagram sekwencji nie może być powiązany z metodą komponentu, gdyż komponenty to element, który wykorzystuje i realizuje zazwyczaj pewien zbiór interfejsów. Metoda (czyli implementacja operacji) jest składnikiem klasy i jest stosowana na diagramach interakcji.
Rozwiązaniem problemu jest wskazanie klas granicznych interfejsu i pokazanie komunikacji pomiędzy komponentami właśnie z użyciem klas.
Na takich diagramach można użyć elementu granicznego Boundary (w Enterprise Architect jest Toolbox w części Common) i zastosowanie go do wskazania granicy pomiędzy komponentami. Ponadto element Boundary można połączyć z odpowiednim klasyfikatorem – komponentem.
W wyniku tego zabiegu otrzymujemy diagram sekwencji zbudowany w oparciu o klasy z jasnym wskazaniem granicy pomiędzy poszczególnymi komponentami
Dokumentując komponent XYZ możemy także użyć tej techniki wskazując na Klasa2 jako klasę inicjującą działanie.
bez nadmiernego „komplikowania” można potraktować komponent jako jego interfejs (który jest także klasą), i traktować komponent jako implementacje tego interfejsu (klasy abstrakcyjnej), wtedy można testować system budując diagram sekwencji bazując w 100% na interfejsach, to da nam test komunikacji bardzo przydatny w projektach integracyjnych.
Ja stosuje nieco inną koncepcję; modeluje interfejsy jako abstrakcyjne klasy interfejsowe, natomiast realizację klas przedstawiam w postaci UC realizujących metody klasy interfejsowej. Łącząc taki UC z wymaganiem na integracje z jednej strony i z komponentem przez klasę interfejsową otrzymuje pełny model integracji od wymagań poprzez komponenty obudowane klasami interfejsowymi oraz realizujące je UC kończąc. Ciekaw jestem opinii co do takiego podejścia?
pozdrawiam
Niestety nie mogę się z nią zgodzić gdyż w takiej konfiguracji zaburza się idea stosowania przypadków użycia (PU), które realizują funkcje systemu a nie klasy. Po drugie PU powinien być wchodzić w interakcję z aktorem. W takiej konfiguracji nie wchodzi w taką interakcję a ponadto mniemam, że swoją „złożonością”, a raczej prostotą koliduje z PU, które reprezentują funkcje systemu. W Enterprise Architect (EA) można wymagana na integracje podłączać -> mapować bezpośrednio na komponenty oraz klasy i interfejsy. Robię wtedy raport z klasami i komponentami wraz z listą wymagań, które muszą być zrealizowane. Raport zawiera diagram komponentów wraz z interfejsami (klasami granicznymi) i pod każdą klasą jest lista wymagań. W EA wymaga to odrobiny wysiłku przy jego pierwszym tworzeniu, ale potem to już F8 i dwa kliknięcia :). Pomocne jest także TORMIGO.
to kwestia porównania chyba. Bliżej opisując „mój sposób”:
– tworzę model dziedziny (metodyką DDD), na początek są to tylko interfejsy (nazwa i umiejętności klasy)
– mając Przypadki użycia dla każdego buduje (diagram sekwencji) jego realizację, bazuje na wzorcu MVC więc komponenty View i Controller (logika pozabiznesowa) są tylko interfejsem a „bebechy” logika biznesowa to model dziedziny systemu.
– uzupełniam atrybuty na bazie tego „co klasa musi wiedzieć by wykonać swoje zadanie” w sekwencji
– teraz implementacja: jedne klasy będą miały swoje Realizacje (projekt implementacji dla programistów) w projekcie a inne pozostaną jako interfejs do dostępnego już innego systemu który „potrafi to co jest potrzebne” czyli Realizuje potrzebny interfejs.
W ten sposób najpierw projektuję system (na papierze) zgodny z wymaganiami a potem dopiero planuję jego implementację. Pojawiają się COTS czyli dostępne gotowce :), bywa, że COTS to wielki ERP a do napisania jest mały dedykowany podsystem… 🙂 ale w tym podejściu wybór konkretnego ERP (albo użycie posiadanego) staje się naturalny i łatwy do obrony.
chyba się rozpisałem 🙂 w zasadzie jest to w 100% z zgodne z OMG->MDA/DDD/MVC
no to mamy chyba nieporozumienie :), inaczej
Aktor otrzymuje od Systemu usługę, jej abstrakcją jest PU (opisuje pragmatykę, w której przypadek użycia to usługa systemu dla Aktora).
Żeby usługa została „wyświadczona” jakieś wewnętrzne zasoby muszą ją zrealizować, na początek analizy niech to będzie BoskiObiekt (celowo nawiązuje do antywzorca o tej nazwie) który to wszystko potrafi, jest nim ów Interfejs czyli abstrakcja tego BoskiegoObiektu. Jako że BoskiObiekt to zmora systemów funkcyjnych, zamieniamy bo w toku analizy OOA na rzeczywistą realizację w postaci „pracy zespołu obiektów”, prace tę opisuje Diagram sekwencji a Obiekty (klasy) są efektem analizy i modelowania dziedziny systemu.
Co mamy?
Każde wymaganie funkcjonalne to jeden PU
Każdy PU ma swój diagram sekwencji (czyli Realizację PU), diagram ten może być rozbudowany (opcje, zagnieżdżenia, itp.)
Każda realizacja korzysta (wykorzystuje klasy) z wspólnego (jednego) modelu dziedziny.
Zależnie od stopnia złożoności każdy Interfejs jest Realizowany przez jedną klasę lub kilka klas i wtedy mamy komponent. Możliwe jest, że jakiś interfejs będzie realizowany przez zewnętrzną aplikację.
Osobiście preferuję traktowanie PU jako wymagań. Wtedy raport PU ewentualnie z ich scenariuszami to specyfikacja wymagań. I tyle dla poszukiwania na rynku gotowego oprogramowania. Dla systemu dedykowanego po protu projektuję dodatkowo realizację PU w opisany sposób.
Na początku analizy nigdy nie zakładam z góry co będzie gotowe a co dedykowane bo to dopiero wynik analizy wskaże optymalne rozwiązanie.
Jarku moja wypowiedź odnosiła się do słów Jacka z resztą Twojej wypowiedzi i jednej i drugiej zasadniczo się zgadzam.
nie widziałem wtedy wypowiedzi Jacka, Ufff