Diagramy komponentów.
http://www.fototube.pl/pictures/umlinterfejsdoesysze
wn.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ę ?

do góry

Użytkownik "sielim" <s...@t...tez.wp.pl> napisał w wiadomości
news:gs4h33$q6i$1@atlantis.news.neostrada.pl...

Ale tu ruch ... ;)
Widzę, że UML normalnie rządzi ;)))

do góry

On 16 Kwi, 08:49, "sielim" <s...@t...tez.wp.pl> wrote:
> Ale tu ruch ... ;)
> Widzę, że UML normalnie rządzi ;)))

napisalbym co o tym sadze, ale nie wiem co to jest Interfejs SC-
SZ3 ;-)

Serio: sprobuj uproscic swoj post. I miej swiadomosc, ze calkiem
sporo
ludu tutaj nie uzywa UMLa (a tym bardziej Enterprise Architecta), bo
im
to nie jest potrzebne ani przydatne. Natomiast ci co uzywaja, robia z
tym
rozne rzeczy i to co im sie sprawdza, nie musi pasowac w twoich
problemach.

-ms

do góry