Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UML, <<extend>>, <<include>>, czasami, zawsze ...

3,097 views
Skip to first unread message

Andrzej S.

unread,
Oct 16, 2007, 1:27:16 PM10/16/07
to
Dzien dobry,

Prosze o pomoc w nastepujacej sprawie:

czy rozróżniając między typami relacji poszerzania <<extend>> i
zawierania <<include>> mogę stosować kryterium "czasami - zawsze"?

np. mając przypadki (jedź pociągiem) i (kup bilet)
stosuję <<include>>, bo jadąc pociągiem zawsze kupuję bilet.

z kolei (jedź pociągiem) i (jedź autobusem) będą połaczone
relacją <<extend>>, bo tylko niekiedy dojedzam do dworca
miejskim autobusem (czasem chodze pieszo).

Czy "czasami - zawsze" jest wystarczającym kryterium?

bardzo dziekuje i pozdrawiam serd.
--
A S

Kardigen

unread,
Oct 16, 2007, 2:22:01 PM10/16/07
to
Andrzej S. pisze:

jak dla mnie to tak, ale muszą to być powiązane logicznie przypadki
użycia :)

andrew

unread,
Oct 17, 2007, 4:22:45 AM10/17/07
to
Użytkownik "Andrzej S." <a...@asas.pl> napisał w wiadomości
news:4714f47f$1...@news.home.net.pl...

Pomijając twój dość zawiły opis... Niestety zauważyłem, że są dwie "szkoły":
a) zgodnie ze specyfikacją UML "include" służy do wskazywania elementów,
które zawsze wystąpią, a "extend" elementów opcjonalnych. I tak chyba
najczęściej się tego używa. Ale nie zawsze.
b) Zgodnie z książką "Applying UML and Patterns" czy książkami R. Martin'a
stereotyp "extend' jest w większości przypadków zbędny i nieporęczny. Służy
od do rozszerzania przypadków użycia bez ingerencji w jego główną treść,
czyli w przypadku, gdy mamy cały use case napisany i nie chcemy go zmieniać,
to w sekcji extends dopisuje się dodatkowe przypadki użycia i punkty
rozszerzenia. Generalnie można się bez tego obyć, ponieważ "include" TEŻ
może być warunkowy, zależnie jak będzie opisany w tekście use case'a.

I tu taka uwaga, diagram to tylko diagram, uwagę trzeba zwrócić głównie na
tekst przypadków użycia (use case).
IMHO extend jest poręczny, bo ładnie wygląda na diagramie, ale w tekście use
case'a lepiej się czyta include'y.

Andrew

Andrzej S.

unread,
Oct 17, 2007, 7:27:23 AM10/17/07
to
Użytkownik andrew napisał:

>
> Pomijając twój dość zawiły opis... Niestety zauważyłem, że są dwie
> "szkoły":
> a) zgodnie ze specyfikacją UML "include" służy do wskazywania elementów,
> które zawsze wystąpią, a "extend" elementów opcjonalnych. I tak chyba
> najczęściej się tego używa. Ale nie zawsze.
[...]

Rozumiem, bardzo dziekuje.
--
A S

0 new messages