To może prostsze pytanie ... Relacja 'pośredniczy w komunikacji' albo 'przenosi dane' - Jak w UML elegancko modelować pośredników w komunikacji ? (logicznie, nie wdrożeniowo)
Subject: To może prostsze pytanie ... Relacja 'pośredniczy w komunikacji' albo 'przenosi dane' - Jak w UML elegancko modelować pośredników w komunikacji ? (logicznie, nie wdrożeniowo)
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ć ... ;)
Subject: Re: To może prostsze pytanie ... Relacja 'pośredniczy w komunikacji' albo 'przenosi dane' - Jak w UML elegancko modelować pośredników w komunikacji ? (logicznie, nie wdrożeniowo)
> 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ć ... ;)
Subject: Re: To może prostsze pytanie ... Relacja 'pośredniczy w komunikacji' albo 'przenosi dane' - Jak w UML elegancko modelować pośredników w komunikacji ? (logicznie, nie wdrożeniowo)
> 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).
> 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ę :)
Subject: Re: To może prostsze pytanie ... Relacja 'pośredniczy w komunikacji' albo 'przenosi dane' - Jak w UML elegancko modelować pośredników w komunikacji ? (logicznie, nie wdrożeniowo)
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.
|
