eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingTo 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)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)
  • Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!newsfeed.neostrada.pl!a
    tlantis.news.neostrada.pl!news.neostrada.pl!not-for-mail
    From: "Wiktor Zychla" <u...@n...com.eu>
    Newsgroups: pl.comp.programming,pl.comp.lang.java,pl.comp.objects
    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)
    Date: Thu, 16 Apr 2009 15:20:31 +0200
    Organization: TP - http://www.tp.pl/
    Lines: 71
    Message-ID: <gs7beo$ocn$1@atlantis.news.neostrada.pl>
    References: <gs72un$3vs$1@atlantis.news.neostrada.pl>
    NNTP-Posting-Host: 195.116.95.201
    Mime-Version: 1.0
    Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response
    Content-Transfer-Encoding: 8bit
    X-Trace: atlantis.news.neostrada.pl 1239888152 24983 195.116.95.201 (16 Apr 2009
    13:22:32 GMT)
    X-Complaints-To: u...@n...neostrada.pl
    NNTP-Posting-Date: Thu, 16 Apr 2009 13:22:32 +0000 (UTC)
    X-Priority: 3
    X-MSMail-Priority: Normal
    X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
    Xref: news-archive.icm.edu.pl pl.comp.programming:181626 pl.comp.lang.java:145585
    pl.comp.objects:17650
    [ ukryj nagłówki ]

    > 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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: