🚀 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