TYPE "Megas":
> Od pewnego czasu probuje sie nauczyc projektowania systemow za pomoca
> narzedzia Enterprise Architect i mam teraz problem. Zaprojektowa?em swoj
> system jako zbior kilku subsystemów (subsystem zamodelowalem jako
> package ze stereotypem <<subsystem>>) ale teraz chcialbym na diagramie
> sekwencji pokazac przeplyw wiadomosci pomiedzy subsystemami. I tu jest
> zonk: Enterprise Architect nie pozwala na przesylanie wiadomosci
> pomiedzy package mowiac ze to nie jest poprawne z punktu widzenia UML.
>
> Zatem pytanko jak Wy modelujecie subsystemy? W jaki sposob modelujecie
> wysokopoziomowy przeplyw informacji pomiedzy subsystemami?
rozróżniłbym modelowanie wysokopoziomowe, które umożliwia opis niemożliwy inaczej lub
trudny, oraz modelowanie dla modelu, czyli by się w niego wpasować (a nie z nim
uzgodnić, lecz wpasować formalnie). tak więc nie potrzebujesz trzymać się modelu
formalnego dla dopisania "UML", lecz dla korzyści, jakie ewentualnie niósłby. do
modelowania możesz po prostu użyć grafów, jeśli wiesz co chcesz osiągnąć i jakimi
metodami, a nie jak to ma wyglądać w zgodności z formalnym zapisem.
co do tzw. 'podsystemów'... nie istnieje coś takiego jak podsystem w etapie
projektowania, 'podsystem' to pojęcie z architektury oprogramowania. nawet jeśli
'podsystem' jest użyty w kontekście "UML" w etapie projektowania oprogramowania, to
--jak to się mówi-- niech, kto to robi, robi to na swoją odpowiedzialność, dla mnie
coś takiego na etapie projektowania nie istnieje inaczej niż jako odwołanie do
pojęcia z architektury tegoż, czyli ewentualnie w postaci granic szkicowanych
przerywaną linią, pomocniczo, dla lepszego wyobrażenia z całością. natomiast tutaj
piszesz wyraźnie o przepływie wiadomości pomiędzy podsystemami, więc chyba o
istnieniu kanałów informacyjnych pomiędzy podsystemami, ale nie o przepływie
wiadomości --nie ten etap.
cya
--
qo |) CPL: cs[0..1] (ss[0..1]) p lvl of curr code!
_x/ , RPL: seg_sel[0..1] privilege lvl of seg_sel!
| ng __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-,
,__ -- __ -- DPL: 2._word_of_seg_desc[13..14]:`f seg_desc ,

do góry

Hej,

Podczas modelowania systemow skladajacych sie z wielu węzłow spotkałem sie z
nowymi problemami, czy moglibyscie mi poradzic jak sobie z nimi radzicie?

1) Moj system bedzie sie skladał z oprogramowania tworzonego na dwa węzły.
Czy przedstawiacie diagram przypadków dla kazdego z węzłów z osobna (dla
jednego węzła drugi jest aktorem), czy raczej wszystko na jednym diagramie
interpretujac dwa węzły jako jeden system.

2) Zastanawiam sie czy zewnetrzne biblioteki wykorzystywane w moim systemie
powinny byc na przedstawiane w architekturze systemu, czy nie. Np. Wiem ze
moj system bedzie wymagał komunikacji TCP/IP, i mam juz gotowa biblioteke
*.dll na te potrzeby. Czy zatem powinienem przedstawicna w architekturze
warstwe odpowiedzialna za komunikacje TCP/IP? 1) Tak: To czy kazda
zewnetrzna biblioteke musze modelowac, nawet uzywana podstawowa biblioteke
STL. 2) Nie: To skad bedzie wiadomo, ze system wymaga komuniakcji TCP/IP.

Dzieki za pomoc...

do góry

Użytkownik "Megas" <k...@o...eu> napisał w wiadomości
news:gq0ahr$8v3$1@news.onet.pl...
>> O ile dobrze pamietam to od wersji 2.0 podsystem to jest _komponent_ ze
>> stereotypem <<subsystem>>. Zmiana ta podyktowana byla dokladnie tym
>> problemem, o ktorym mowisz - czyli ze pakiet nie jest klasyfikatorem.
>>
>
> Nie za bardzo mi pasuje ta koncepcja, gdyz komponent nie rozroznia
> interfejsow dla roznych klas, czyli:
> Jesli w subsystemie mam dwie klasy reprezentujace interfejs, i one
> posiadaja funkcje o takiej samej nazwie, np: IClass1:Start();
> IClass2:Start(). To komponent reprezentujacy ten subsystem bedzie posiadal
> tylko jedna funkcje jako interfejs: Start() i nie wiadomo do ktorej jest
> to odwołanie.

Nie wiem, czy dobrze zrozumiałem, ale komponent raczej sam w sobie nie ma
'Funkcji',
nie w tak niskopoziomowym sensie. Za to pod EA jest coś takiego jak 'Expose
Interface'.
I jeśli masz podefiniowane własne interfejsy to automatycznie Ci się pokażą
w liście wyboru.

W ten sposób nie interesuje cię czy w różnych interfejsach metody nazywają
się tak samo czy inaczej. Robisz komponent reprezentujący jakiś podsystem i
eksponujesz
jego interfejsy (a w nich już możesz sobie konkretnie mieć jakie funkcje
chcesz).

Jak chcesz na diagramie wskazać konkretną klasę, która dany interfejs
implementuje w danym
konkretnym komponencie to możesz tę klasę umieścić wewnątrz komponentu (może
na osobnym
diagramie pokazującym już wewnętrzną strukturę/implementację podsystemu), w
niej także eksponować
dany interfejs i połączyć oba interfejsy relacją 'Delegate'. nie mam
pojęcia, czy to jest zgodne z UML'em,
z jaką wersją itp, ale wydaje mi się całkiem zgrabne i przejrzyste przy
modelowaniu interfejsów
międzysystemowych ;)

Dla mnie dużo większym problemem jest modelowanie różnorodności konfiguracji
kiedy np.
ten sam system jest wdrażany u różnych klientów i u każdego dany interfejs
zewnętrzny może
być delegowany wewnętrznie do innego komponentu implementującego itp. lub
występują
inne warianty implementacji w środowisku deweloperskim, w środowisku do
testów funkcjonalnych,
w środowisku do testów obciążeniowych ... Czyli generalnie: temat
wersjonowania, konfiguracji
wariantowości połączeń między systemami. To raczej problem organizacji tego
wszystkiego na diagramach,
niż samych możliwości technicznych UML'a w EA.

do góry