http://www.fototube.pl/pictures/umlinterfejsyprzykla
d2.png

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.

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

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ć ... ;)

do góry

> 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

do góry

Użytkownik "Wiktor Zychla" <u...@n...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/dy
namic_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ę :)

do góry

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

do góry