🚀 go-pugleaf

On Thu, 20 Sep 2007 21:39:50 +0200, Piotr Dembiński wrote:

>> Więc podaj jakiś lepszy przykład. Sam jestem ciekaw.

To co, będzie jakiś przykład?

>> Zależy od poziomu abstrakcji ;J
>
> Chodzi właśnie o poziom abstrakcji. 'Kompiluj' i 'zbuduj' to
> będą metody klas, a 'redagowanie tekstu' to będzie przypadek
> użycia. Tak to widzę.

Ja widzę tak, że jeśli IDE jest pewnym systemem, z którym
użytkownik [aktor] pracuje, to "Skompiluj moduł" i "Zbuduj
cały projekt" [a nie "Kompiluj" u "Zbuduj"] będą przypadkami
użycia, bo są to sposoby, w jakie użytkownik chce używać
tego systemu. "Edytowanie kodu źródłowego" także jest
przypadkiem użycia IDE, nie przeczę. I chociaż przypadki
użycia często przekładają się w jakimś stopniu na metody
klas [jeśli IDE byłoby jedną wielką spasioną klasą :P],
to jednak na tym etapie nie traktuję ich jeszcze jako
metody klasy czy funkcje programu, bo przypadki użycia są
jak dla mnie bardziej abstrakcyjne i nie mówią jeszcze nic
o sposobie ich zaimplementowania w programie [czy to w
postaci metod klasy, czy zbioru metod wielu klas, czy
jakichś luźnych funkcji]. Jest to po prostu system widziany
oczami użytkownika, "na powierzchni", bez zagłębiania się
w szczegóły jego działania i realizacji poszczególnych zadań.

>> Tak do sprawy podchodząc, to mógłbym nawet zrobić jeden
>> przypadek użycia: "Używaj IDE" :P
>
> Jeśli projektujesz system, którego IDE jest tylko częścią
> (np. system obsługi całego cyklu życia oprogramowania), to
> wcale nie jest to absurdalne :)

Wiesz, z pewnego punktu widzenia to nawet słoń może wyglądać
jak mrówka ;J ale ja tutaj mówię o konkretnym przykładzie
[moim], a nie takim, w którym IDE jest tylko częścią systemu :P
Więc nie odbiegaj od tematu tylko po to, by z jakiegoś
odległego punktu widzenia mogło wyjść na twoje ;J

>> Dlatego uważam, że mój przykład jest dobry,
>
> Nie jest, zwłaszcza że -- jak napisałem uprzednio -- wprowadza
> w błąd osobę czytającą diagram.

Więc mi to udowodnij. Samo "nie jest" i "wprowadza w błąd"
nic dla mnie nie znaczy.

>> dopóki nie interesują nas szczegóły implementacji tych
>> przypadków użycia, czyli jak dokładnie te zadania są
>> realizowane.
>
> To, co podałeś, to nazwy metod, a nie przypadki użycia.

Możliwe, że z twojego punktu widzenia tak to wygląda,
jednak nadal nie chcesz wykazać mi różnicy, więc
nie potrafię dojść do tego, dlaczego tak ci się wydaje ;)

>>> Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.
>>
>> Nie ma sprawy, pokaż mi różnicę ;) Człowiek się całe życie
>> uczy.
>
> Różnica polega właśnie na złożonej kooperacji. Innymi słowy --
> pojęcie funkcji systemu jest IMO pojęciem znaczeniowo szerszym od
> pojęcia przypadku użycia.

Aha... to super... fajnie godosz :>  ino mało konkretnie ;)

>> Nie musi, bo nie musi wykonywać dołączanego przypadku użycia
>> "ręcznie". MOŻE to jednak zrobić i kompilować sobie każdy moduł
>> ręcznie, zgodnie z pierwszym z tych przypadków użycia ;)
> 
> Dlatego to są nazwy metod, a nie przypadki użycia.

Ja nie widzę, jak jedno miałoby wynikać z drugiego.

-- 
SasQ