🚀 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 

Użytkownik "Wiktor Zychla" <user@nospam.com.eu> napisał w wiadomości 
news:gs7beo$ocn$1@atlantis.news.neostrada.pl...

> 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.

OKI, masz rację, chcę głównie skupić się na architekturze, bo procesy 
generalnie
są tu proste - zawsze chodzi o przesłanie informacji 'na drugą stronę', 
tylko róznych
narzędzi siędo tego używa - raz Mule, raz skrypy bash bezpośrednio 
korzystajace
z klienta SSH, innym razem jakiegoś natywnego softu wbudowanego w MQ
(np. WebSphere MQ File Transfer). Nie chciałem tych komponentów na diagramie
architektury zostawiać 'niezwiązanych' tylko jasno wskazać - 
'budują/zarządzają
kanałem komunikacji'

> 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).
Myślisz o diagramie procesów tu, jak poniżej ?:
http://www.sparxsystems.com.au/resources/tutorial/dynamic_model.html

> 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?
Jak już będę miał te diagramy to linki jak najbardziej. Jak nie będzie trego
za dużo, to pod Enterprise Architect'em można nawet zastosować link typu
'diagram frame' - gdzie mi od razu podglad zrobi tam, gdzie linkuję.

> 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.

Tak, same dane krążące w interfejsie już zbieram osobno na czymś bardzo 
podobnym
do standardowego 'Modelu Danych', ale wydzielam do osobnego pakietu 
Interfejsy.

Dzięki za podjęcie tematu, już straciłem nadzieję :) 

> Myślisz o diagramie procesów tu, jak poniżej ?:
> http://www.sparxsystems.com.au/resources/tutorial/dynamic_model.html

akurat myślałem o d.czynności ale skoro oba są behavioralne, to w tym 
przypadku chyba wybór między nimi jest kwestią subiektywną.

> Jak już będę miał te diagramy to linki jak najbardziej. Jak nie będzie 
> trego
> za dużo, to pod Enterprise Architect'em można nawet zastosować link typu
> 'diagram frame' - gdzie mi od razu podglad zrobi tam, gdzie linkuję.

tego nigdy nie próbowałem.

chyba rozumiem dlaczego chciałeś mieć wszystkie komponenty na jednym 
diagramie - właśnie dlatego, że chciałeś mieć diagram architektury.

tylko, że ponieważ te mule, kolejki i reszta fauny jest specyficzna dla 
procesu wymiany, to co najwyżej w diagramie architektury do samego 
połączenia interfejsami między System1 a System2 dodałbym odnośnik do 
takiego diagramu opisującego szczegóły procesu.

oczywiście wtedy z diagramu architektury to zniknie, ale to Twój wybór - czy 
mieć jeden diagram z architekturą i szczegółami procesu, czy lepiej kilka 
diagramów, co najwyżej połączonych ze sobą jakimiś linkami.

Wiktor Zychla