Relacje między komponentami

Witam

Mam drobną nieścisłość w kwestii relacji między dwoma większymi Komponentami w Systemie Wymiany akcji. Piorąc pod uwagę poniższy diagram zastanawiam się nad połączeniem Klienta I serwera w relacji asocjacji w niżeli generalizacji w które Klient miałby dostęp do wszystkich funkcjonalności Servera niżeli tylko do częśc np: Sesja, baza akcji, Analizator.
Chyba iż jest to niezbędne do komportowego korzystania z systemu przez maklera.

poza tym w samej dokumentacji do diagramu powieniem ująć dokładnie wszystkie realacje między komponentami chyba, że tylko te najistotniejsze :-p

Może się mylę, ale nawet jakby zaimplementować obecny stan systemu to niewiele w praktyce się widzi...

Witam! Masz rację co do relacji – asocjacja między Klientem a Serwerem (np. 1:1 lub 1:* z metodami jak login(), getSession(), queryActions()) będzie precyzyjniejsza niż generalizacja, bo makler nie dziedziczy wszystkiego z Servera (nie edytuje bazy bezpośrednio, tylko korzysta z fasady: Sesja + Analizator + baza akcji via API). Generalizacja sugeruje pełny dostęp (is-a), a asocjacja – kontrolowany (has-a lub uses-a), co pasuje do architektury klient-serwer z warstwą abstrakcji.
​

W dokumentacji do diagramu UML wklej wszystkie relacje (asocjacje, agregacje, kompozycje, zależności) z multiplicities i kierunkiem strzałek – np. Klient --1..*--> Sesja (makler ma jedną sesję), Serwer *<>--1 BazaAkcji (kompozycja, bo bez bazy serwer nie działa). Ogranicz do najistotniejszych tylko w executive summary, ale pełny widok musi być kompletny, by uniknąć niejasności przy implementacji.
​

SIBO

Opisałem juz widok interakcji między komponentami z punktu widzenia Clienta oraz Servera. Opisałem tez Interakcje miedzy komponentami z poziomu Servera.

Zawarłem sposób przekazywania informacji oraz krótko procesy zachodzące między komponentami systemu.
Od siebie dodałem Komponent: Przypomnienia hasła po za klientem oraz Serverem, Administracyjny w relacji z Klientem oraz Skaner wybranego sektora gospodarczego.

Posiłkowałem się tez materiałem : System Architecture Documentation Best Practices and Tools(freeCodeCamp) aczkolwiek przykładów takich dokumentow nie znalazłem, a wiem, że rodzaj dokumentacji jest ok 10 roznych.
Jest ktoś w stanie polecic jakiś materiał ? Ew wzorować się na dokumentacji produktu Oracle..

Nie mogę obojętnie przejść wobec Twoich postów @delform_17 Po prostu nie mogę patrzeć na diagramy, które produkujesz ;-)

Spójrz na diagram z inicjalnego posta, w którym używasz notacji lizaka na diagramie komponentów.

Zgodnie z tym diagramem:

• GUI wystawia interfejs dla innych komponentów (---O),
• Stock Portfolio i Client Session potrzebują GUI do działania (---().

Czy naprawdę o to Ci chodziło, że Stock Portfolio wymaga GUI do działania?
Jeśli nie, to proponuję zacząć od tej książki.

Nie zaczynaj od przypadkowej dokumentacji z internetu ani od tworzenia diagramów bez jasno określonego celu. Diagramy powinny być użyteczne, a nie tworzone pro forma.
Wspomniana książka powinna dać Ci ogólny obraz tego, jak wygląda proces projektowania systemu i jak to pogodzić z iteracyjnym podejściem.

1. Ustalasz, co w systemie można zrobić. Raczej nie masz gotowca, tylko trzeba porozmawiać z ludźmi i doprecyzować wymagania -> diagramy przypadków użycia
2. W ramach prac koncepcyjnych porządkujesz pojęcia, reguły -> diagram koncepcyjny (diagram klas na wysokim poziomie ogólności, pokazujący relacje między pojęciami, a rzadziej atrybuty, jak już się pojawiją to są istotne biznesowo).
3. Rozkładasz przypadki użycia na kroki. Tu powinno się powoli pojawiać pomysły na rozdzielenie odpowiedzialności, a więc zalążki komponentów.
4. Tworzysz diagramy sekwencji, żeby zobaczyć, jak to spina się „na papierze”. Często się nie spina -> korekty komponentów i odpowiedzialności. Niektóre z tych komponentów mogą leżeć poza granicami (będziesz interfejsował z czymś, wystawiasz intefejsy logiczne)
5. Dopiero później przechodzisz do diagramu komponentów i interfejsów.
6. Kontrakaty dla interfejsów / technologia -> implementacja.

Moim zdaniem Twój diagram komponentów wnosi więcej szkody niż pożytku. Dla programisty raczej istotne byłyby zrozumienie tych aspektów nad którymi ma pracować, np. jeśli masz taki uproszczony diagram sekwencji dla hipotycznego skłądania zlecenie kupna instrumentu finansowego

To dla programisty będzie za mało, żeby coś sensownego wyprodukować, ale taki diagram ma wartość dla dalszej pracy i jest bazą do ustalenia kontraktów interfejsów oraz wyborze technologii i sposobu integracji pomiędzy tymi komponentami (zauważ, że do realizacji przypadku użycia, nie ma znaczenia czy wowłania będa synchroniczne/asynchroniczne, czy w ramach procesu, czy rozproszone, czy repozytorium o będzie baza danych RDBMS, czy bucket S3 itd.). W późniejszym etapie może dokumentować, to jak wygląda składanie zamówienia.

Po co tworzysz te swoje diagramy? Co i komu mają ułatwiać?

Licze na to, ze post nie wywolal skrajnie negatywnych emocji.

W zwiazku z protfolio akcji i klientem sesji to sadze oba komponenty potrzebuja grafiki aby to dzialalo a na pewno ewidencja portfela akcji.
g
Z ksiazka, a przynajmniej jej rozdzialami sie zapoznalem i w sumie ciekawa pozycja ;) Ten diagram jest jednym z trzech ktore utworzylem w ramach treningu aby zrozumiec istote, dzialania i prawa rzadzace tym elementem projektowania aplikacji.
Wiem , ze kazdy diagram jest inny , bo Inzynierowie rozne go ujmuja w zaleznosci od wymagan klienta.
Chcialem tylko wiedziec co powinno sie zawierac w dokumentacji ktora opsuje to czego nie widac na diagramie.

Wiem, ze diagram nie zawsze jest potrzebny, bo mamy rozne narzedzia do dyspozycji. Nawet w ksiazce dr. Sachy jest na to poswiecona skomna czesc...
Stalem sie tutaj raczej wlasciwie ujac relacje miedzy koponentami, nie kazdy skladnik systemu musi miec do wszystkiego dostep.

Ale dziekuje za wydedukowanie mi istoty zagadnienia.

Pytanie tylko jakie elementy w tym przykladzie wprowadzaja najwiecej haosu i co jest niesprecyzowane.

delform_17 napisał(a):

Chcialem tylko wiedziec co powinno sie zawierac w dokumentacji ktora opsuje to czego nie widac na diagramie.

To diagram komponentów, więc masz komponenty i interfejsy. Na diagramie nie pokażesz szczegółów dotyczących interfejsów -> to się powinno znaleźć w dokumentacji.

Pytanie tylko jakie elementy w tym przykladzie wprowadzaja najwiecej haosu i co jest niesprecyzowane.

Moim zdaniem niekomplenty i zbyt ogólny:

• z czym interfejsuje Portfolio Database i Stock Market Analizer ?
• nazwy interfejsów (Request/Response), Interface? (serio nazwa Interface dla interfejsu logicznego?)

Diagrramów, czy ogólnie dokumentacji nie nalezy robić po to, żeby była, tylko żeby rozwiązywała jakiś problem w twoim projekcie/systemie. UMLowe diagramy komponentów są moim zdaniem mało efektywnym sposobem przekazywania wiedzy w dzisiejszych czasach i dzisiejszych architekturach.
Jeżeli masz klienta i serwer/serwery, to zwykle wystarczy umieścić na diagramie informację, że jest serwer, udostęnia interface'y REST/SOAP/WS, czy co tam jest użyte. Jak serwerów jest więcej i klient ma z nimi do czynienia, to też wrzuca się je w to miejsce. Detale dotyczące tego co faktycznie oferuje serwer można wrzucić w jakieś OpenAPI, bo ktoś kto chce sprawdzić np. kurs akcji i tak nie będzie tego szukać na diagramie, tylko wejdzie sobie w jakiś dokument, czy na stronkę Swaggera.
Jeżeli masz jakieś proste mikroserwisy, to diagram pokazujący co one mają w środku jest IMO kompletnie zbędny, bo i tak nikt nigdy z niego nie skorzysta.
Bardziej złożone interakcje pomiędzy kontenerami/komponentami lepiej umieścić na diagramie sekwencji i to akurat dokumentacja potrzebna, bo ciężko "z kodu" wyczytać jak ma przebiegać jakieś złożone logowanie, czy inne sagi, szczególnie jeżeli ten kod jest rozproszony na choreografię kilkunastu kontenerów.

Bardzo polecam podejście C4 (context, container, component, code) do organizacji takich diagramów. Czytający w 5 minut jest w stanie zrozumieć z kim/czym system się komunikuje, jakie są jego elementy, w razie potrzeby sprawdzić co w tych elementach się znajduje. Z zastrzeżeniem, że nie każdy system, czy element tego systemu potrzebuje pełnej dokumentacji.