> 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