🚀 go-pugleaf

Diagramy komponentów.
http://www.fototube.pl/pictures/umlinterfejsdoesyszewn.png

Mam taką sytuację: jest pewien systemik, którego zadaniem
jest budowa interfejsu między dwoma innymi systemami. A że
interfejs jest duży, to sam interfejs stanowi dość złożony system,
w każdym bądź razie składa się z wielu komponentów.

Mam duży sytem centralny i mnóstwo interfejsów do innych
systemów - niektóre z nich złożone jak wyżej.

Chcę uzyskać ogólną mapę systemów. Bez wdrożeniówki, od strony
logicznej, chcę uzyskać coś takiego, że na diagramie ogólnym modeluję
wszystkie systemy jako komponenty i buduję między nimi ogólne,
abstrakcyjne interfejsy, expose (provided/required), łączę i mam.

Dla wybrango interfejsu na osobnym diagramie komponentów modeluję
więcej szczegółów:
- struktury danych wymieniane w ramach interfejsu - np. że
jest to kilka plików z danymi a oprócz tego istnieje wymiana wiadomości
- pośredników w komunikacji: że istnieje serwer MQ a na nim konkretne
kolejki, które są dedykowane do różnych rodzajów wiadomości, niektóre
pliki idą dodatkowo przez ssh, a jeden jest wpychany do MQ (teoretycznie,
choć to już mocno przekombinowane)

Tutaj mam próbkę modelowania kawałka czegoś takiego, z uwzględnieniem
wiadomosci przesyłanych przez MQ, bez tematu plików (a szkoda ... ale
żeby nie zamotać).

Staram się to wszystko zawrzeć na diagramach statycznych (komponentów),
żeby opisać wszystkie istniejące komponenty i relacje między nimi.

Pierwszy problem:
- jak zrealizować (pod Enterprise Architectem) eleganckie zejście 'w dół'.
Ja tam spróbowałem wcisnać nieco sztuczny komponent Interfejs SC-SZ3,
jego przerabiam jako Composite Element - no i można klikać. Tylko że to jest
komponent bardzo abstrakcyjny - który potem na diagramach wdrożeniowych
w ogóle nie będzie istniał, bo zawiera

Drugi problem:
- jak w ogóle modelować tematykę serwerów MQ, kolejek, wiadomości ?
Po części jak bazę danych, ale jednak inaczej.
Wiadomości to struktury danych - wiec niech będzie klasa ze stereotypem
'message'. Ale teraz mam takie byty jak serwer MQ (komponent) i na nim
kolejki (znów komponenty ? ja to zrobiłem jako obiekty - instancje klasy
MessageQueue).
I jak potem elegancko te relacje narysować na diagramie ?
Załóżmy, że mam dwa spięte serwery MQ - jeden po jednej stronie interfejsu,
drugi po drugiej, ze spiętymi kolejkami (np. dwa spięte serwery IBM MQ).
Chciałbym mieć to elegancko na jednym diagramie j.w, ale pojawia się 
problem,
że w obu lokalizacjach spięte kolejki nazywają się tak samo i nie bardzo 
mogę je
na jednym diagramie wrzucić. Może w ogóle nie pokazywać na logicznych
powiązaniach, że są dwa serwery ? Ale to też niedobrze, bo one nie są 
identyczne,
każdy z nich ma jeszcze kolejki lokalne, niewidzialne po drugiej stronie ...

Trzeci problem:
- użyłem relacji <flow> do pokazania w którą stronę jakie wiadomosci krażą.
Jednocześnie jednak ciągle mi brakuje wyrazistego wskazania, że te 
wiadomości
(struktury danych) logicznie składaja się na "interfejs systemu 3" i ta 
nadmiarowość
- na diagramie szczegółowym mam niepotrzebnie dalej tę relację'assembly' - 
tak
jakby ona byłą czymś osobnym. Może usunąć (ukryć) assembly z diagramu
uszczegółowiajacego, przenieść to 'kółeczko" (interfejs) na diagram 
szczegółowy
i każdą strukturę danych, którą on zawiera powiązać ? Może tak ... A może 
dać
sobie spokój i na osobnym diagramie modelować wymieniane struktury danych 
(po stronie
systemu, który dany interfejs 'providuje' ?), a na osobnym kwestie połączeń 
?
No ale gdzie wtedy pokazać dokładnie, które kolejki MQ służą do wymiany
których wiadomości (kolejki są ściśle dedykowane) ?

Czwarty problem:
- jak modelować pliki wymiany danych: czy jako dokumenty/artefakty,
czy może konsekwentnie, jak wyżej wiadomości MQ - jako obiekty jakichś
klas 'Text/XML File', które mają jakąś zgrubną strukturę ?