eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingModelowanie interfejsów międzysystemowych w UML (Enterprise Architect)
Ilość wypowiedzi w tym wątku: 3

  • 1. Data: 2009-04-15 11:38:17
    Temat: Modelowanie interfejsów międzysystemowych w UML (Enterprise Architect)
    Od: "sielim" <s...@t...tez.wp.pl>

    Diagramy komponentów.
    http://www.fototube.pl/pictures/umlinterfejsdoesysze
    wn.png

    Mam taką sytuację: jest pewien systemik, którego zadaniem
    jest budowa interfejsu między dwoma innymi systemami. A że
    interfejs jest duży, to sam interfejs stanowi dość złożony system,
    w każdym bądź razie składa się z wielu komponentów.

    Mam duży sytem centralny i mnóstwo interfejsów do innych
    systemów - niektóre z nich złożone jak wyżej.

    Chcę uzyskać ogólną mapę systemów. Bez wdrożeniówki, od strony
    logicznej, chcę uzyskać coś takiego, że na diagramie ogólnym modeluję
    wszystkie systemy jako komponenty i buduję między nimi ogólne,
    abstrakcyjne interfejsy, expose (provided/required), łączę i mam.

    Dla wybrango interfejsu na osobnym diagramie komponentów modeluję
    więcej szczegółów:
    - struktury danych wymieniane w ramach interfejsu - np. że
    jest to kilka plików z danymi a oprócz tego istnieje wymiana wiadomości
    - pośredników w komunikacji: że istnieje serwer MQ a na nim konkretne
    kolejki, które są dedykowane do różnych rodzajów wiadomości, niektóre
    pliki idą dodatkowo przez ssh, a jeden jest wpychany do MQ (teoretycznie,
    choć to już mocno przekombinowane)

    Tutaj mam próbkę modelowania kawałka czegoś takiego, z uwzględnieniem
    wiadomosci przesyłanych przez MQ, bez tematu plików (a szkoda ... ale
    żeby nie zamotać).

    Staram się to wszystko zawrzeć na diagramach statycznych (komponentów),
    żeby opisać wszystkie istniejące komponenty i relacje między nimi.

    Pierwszy problem:
    - jak zrealizować (pod Enterprise Architectem) eleganckie zejście 'w dół'.
    Ja tam spróbowałem wcisnać nieco sztuczny komponent Interfejs SC-SZ3,
    jego przerabiam jako Composite Element - no i można klikać. Tylko że to jest
    komponent bardzo abstrakcyjny - który potem na diagramach wdrożeniowych
    w ogóle nie będzie istniał, bo zawiera

    Drugi problem:
    - jak w ogóle modelować tematykę serwerów MQ, kolejek, wiadomości ?
    Po części jak bazę danych, ale jednak inaczej.
    Wiadomości to struktury danych - wiec niech będzie klasa ze stereotypem
    'message'. Ale teraz mam takie byty jak serwer MQ (komponent) i na nim
    kolejki (znów komponenty ? ja to zrobiłem jako obiekty - instancje klasy
    MessageQueue).
    I jak potem elegancko te relacje narysować na diagramie ?
    Załóżmy, że mam dwa spięte serwery MQ - jeden po jednej stronie interfejsu,
    drugi po drugiej, ze spiętymi kolejkami (np. dwa spięte serwery IBM MQ).
    Chciałbym mieć to elegancko na jednym diagramie j.w, ale pojawia się
    problem,
    że w obu lokalizacjach spięte kolejki nazywają się tak samo i nie bardzo
    mogę je
    na jednym diagramie wrzucić. Może w ogóle nie pokazywać na logicznych
    powiązaniach, że są dwa serwery ? Ale to też niedobrze, bo one nie są
    identyczne,
    każdy z nich ma jeszcze kolejki lokalne, niewidzialne po drugiej stronie ...

    Trzeci problem:
    - użyłem relacji <flow> do pokazania w którą stronę jakie wiadomosci krażą.
    Jednocześnie jednak ciągle mi brakuje wyrazistego wskazania, że te
    wiadomości
    (struktury danych) logicznie składaja się na "interfejs systemu 3" i ta
    nadmiarowość
    - na diagramie szczegółowym mam niepotrzebnie dalej tę relację'assembly' -
    tak
    jakby ona byłą czymś osobnym. Może usunąć (ukryć) assembly z diagramu
    uszczegółowiajacego, przenieść to 'kółeczko" (interfejs) na diagram
    szczegółowy
    i każdą strukturę danych, którą on zawiera powiązać ? Może tak ... A może
    dać
    sobie spokój i na osobnym diagramie modelować wymieniane struktury danych
    (po stronie
    systemu, który dany interfejs 'providuje' ?), a na osobnym kwestie połączeń
    ?
    No ale gdzie wtedy pokazać dokładnie, które kolejki MQ służą do wymiany
    których wiadomości (kolejki są ściśle dedykowane) ?

    Czwarty problem:
    - jak modelować pliki wymiany danych: czy jako dokumenty/artefakty,
    czy może konsekwentnie, jak wyżej wiadomości MQ - jako obiekty jakichś
    klas 'Text/XML File', które mają jakąś zgrubną strukturę ?


  • 2. Data: 2009-04-16 06:49:01
    Temat: Re: Modelowanie interfejsów międzysystemowych w UML (Enterprise Architect)
    Od: "sielim" <s...@t...tez.wp.pl>


    Użytkownik "sielim" <s...@t...tez.wp.pl> napisał w wiadomości
    news:gs4h33$q6i$1@atlantis.news.neostrada.pl...

    Ale tu ruch ... ;)
    Widzę, że UML normalnie rządzi ;)))


  • 3. Data: 2009-05-13 19:33:38
    Temat: Re: Modelowanie interfejsów międzysystemowych w UML (Enterprise Architect)
    Od: matmis <m...@g...com>

    On 16 Kwi, 08:49, "sielim" <s...@t...tez.wp.pl> wrote:
    > Ale tu ruch ... ;)
    > Widzę, że UML normalnie rządzi ;)))

    napisalbym co o tym sadze, ale nie wiem co to jest Interfejs SC-
    SZ3 ;-)

    Serio: sprobuj uproscic swoj post. I miej swiadomosc, ze calkiem
    sporo
    ludu tutaj nie uzywa UMLa (a tym bardziej Enterprise Architecta), bo
    im
    to nie jest potrzebne ani przydatne. Natomiast ci co uzywaja, robia z
    tym
    rozne rzeczy i to co im sie sprawdza, nie musi pasowac w twoich
    problemach.

    -ms

strony : [ 1 ]


Szukaj w grupach

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: