🚀 go-pugleaf

> Czyli prosta sprawa:
> mam dwa systemy, jeden dostarcza własny interfejs dostępu (Provides 
> Interface), drugi z tego interfejsu korzysta
> (Required Interface).
> Na interfejs składają się powiedzmy dwa(trzy) podinterfejsy:
> - cześć informacji jest raz dziennie wysyłana z pomocą plików (np. 
> rozliczenia transakcji finansowych)
> - cześć informacji jest przesyłana na bieżąco w ciągu dnia w postaci 
> małych wiadomości o formacie XML,
> wiadomości są przepychane za pośrednictwem MQ
> - alternatywnie informacje są przekazywane za pomocą webserviceu a nie 
> MQ - bezpośrednie metody send/recieve.

moim zdaniem chyba niepotrzebnie chcesz to upchnąć na jednym diagramie.
Twój diagram niepotrzebnie próbuje mieszać architekturę systemu z 
implementacją procesów.

ja bym zrobił kilka diagramów.

do opisania samej koncepcji integracji być może wystarczy to co masz na 
dole, czyli diagram architektury z System1 vs System2 i ilomaś interfejsami.
przy każdym interfejsie można zrobić notkę opisującą czego dotyczy dany 
interfejs (że jest używany raz dziennie albo na bieżąco i jakich danych 
dotyczy itd. itp).

> Przykładowo: do przesyłania plików używam MuleESB, który zasysa pliki ze 
> wskazanych katalogów,
> wpycha je w SSH i tym sposobem pojawiają się po drugiej stronie. Zresztą 
> mule może to zrobić
> inaczej, nie przez SSH, ale np. także przez kolejkę MQ. Ale to pomińmy.

no właśnie do tego fajnie nadawałby się jakiś diagram procesu (czynności), 
żeby pokazać w partycjach te Mule i inne zwierzęta i to w jaki sposób dane 
między nimi fizycznie płyną. możnaby ładnie proces zamodelować jako 
wariantowy (jeśli są warianty).

> Ważne jest to, że
> mam te dwa systemy - komponenty, mam też komponent Mule z podkomponentem 
> FileExporter
> (kawałek konfiguracji), mam też kilka klas/obiektów, które reprezentują 
> przesyłane pliki(dane)
> i chcę to ładnie, przejrzyście powiązać relacjami, które powiedzą: 
> "transportem plików X,Y
> składających się na interfejs międzysystemowy IM1 zajmuje się FileExporter 
> schowany w Mule"

no i może do każdego z interfejsu z pierwszego diagramu zrobić właśnie link 
do diagramu opisującego taki fizyczny proces przesyłania danych?

potem ostatecznie też gdzieś w modelu pojęciowym będziesz miał opisane te 
dane, możnaby wtedy porobić linki (zależności) między z jednej strony 
modelem pojęciowym, z drugiej - procesami przekazywania tych danych, z 
trzeciej modelem architektury gdzie będą namalowane podsystemy składowe i 
warunki przekazywania danych.

> I podobnie z MQ:
> "transportem wiadomosci M1,M2 składających się na interfejs 
> międzysystemowy IM2
> zajmuje się MQ (np. Active MQ) za pośrednictwem kolejki Q"
>
> Pewna szybko nakreśłona propozycja diagramu (do uzupełnienia relacjami lub 
> może opisami ?)
> w linku na początku.
>
> Przepraszam javovców, że temat lekko oftoppowy, ale na innych grupach 
> straszna bida jest.
> Nikt się w UMLu nie chce bawić ... ;)

pozdrawiam
Wiktor Zychla