🚀 go-pugleaf

andrew napisał(a):
> U�ytkownik "yapann" <yapann@odwa.pl> napisa� w wiadomo�ci
> news:fjtmjv$hih$1@nemesis.news.tpi.pl...
> > widz�, �e z biegu wypoewiedzia�am si� w starym w�tku - grupa jako� ledwo
> > dycha - zabawne, czy ma�o w�tpliwo�ci miewamy z OO, czy te� ma�o poddajemy
> > w�tpliwo�ci :]
>
> Raczej ma�o os�b wie, �e w og�le taka grupa istnieje (i czego tyczy si�
> "objects" w nazwie) i wi�kszo�� zapyta� idzie na pl.comp.programming/lang.c.
>
> Andrew

Osobiście jestem za tym by najpierw określić granice projektowanego
systemu: gdzie system a gdzie jego klient. GIU może być raz klientem a
raz elementem systemu.

Pojęcie aktora rodzi wiele emocji i niejednoznaczności na diagramach
(bo granice systemu mogą być rózne w różnych projektach) i to moim
zdaniem powoduje, że w licznych projektach aktorem są tak różne
rzeczy, że żadna semantyka ani tym bardziej semiotyka tego nie
obejmuje. Skutek: zamawiajacy odbiera taka dokumentuję nie rozumiejąc
jej tak jak jej autor. Wszyscy wiemy jakie są konsekwencje.


Ja, by zachować we wszystkich moich projektach spójność semantyczną,
zachowuję zasadę:
- aktor to człowiek majacy kontakt z systemem, zawęża to pojęcie
aktora jednak daje prostą semantykę i syntaktykę: aktor to czowiek a
model UC to model wymagan funkcjonalnych systemu z perspektywy
użytkownika.

W kazdym innym przypadku nie używam pojęcia aktora tylko interfejsu.
Jeżeli projektuję system fakturowania pisze "juzkejsy" ale tylko po to
by zatwierdził je odbiorca (bo tę specyfikację on przeczyta ze
zrozumieniem). Jeżlei projektuję system obsługi transmisji plikow
przez sieć to używam interfejsów a nie aktorów.

W Twoim przypadku ja bym aktorem nazwał tylko użytkownika, który używa
GUI, łącze pomiędzy GIU a głębszymi warstwami to już u mnie tylko
interfejsy i komponenty. Polecam książeczkę: "Komponenty w UML".


To pozwala mi utzrymać jednolite zasady modelwoanai dla bardzo nawet
róznych projektów.