🚀 go-pugleaf

On Tue, 8 Nov 2005 08:39:16 +0000 (UTC), "rr"
<rradz@WYTNIJ.gazeta.pl> wrote:

>witam
>
>Spotkałem się ostatnio z opiniami (nie wiem na ile słusznymi, bo nie jestem
>specem od OOP i UML'a, stąd Was pytam) że UML dobry jest może do samego OOP,
>ale nie nadaje się zbytnio do modelowania, jeśli wykorzystujemy programowanie
>współbieżne, rozproszone, czy techniki typu constraint programming.
>
>Jeśli to prawda, to czy jest w takim razie jakaś alternatywa? Może Mozart/Oz
>(jako środowisko multiparadygmatowe, wspierające w/w techniki) ma coś w
>zanadrzu? A może da się modelować z wykorzystaniem np. Prologa takie rzeczy?

Co to znaczy "modelowac z wykorzystaniem Prologa"?... Co to znaczy
"modelowac" w ogole?..

A UML  rzeczywiscie sie nir nadaje do niczego.

A.L.

> Co to znaczy "modelowac z wykorzystaniem Prologa"?... Co to znaczy
> "modelowac" w ogole?..

Chodzi mi o stworzenie schematu/opisu działania aplikacji. 

> A UML  rzeczywiscie sie nir nadaje do niczego.

Dlaczego do niczego? Poza tym, może OCL Waszym zdaniem będzie stosunkowo
wystarczający do opisywania (modelowania) takich mechanizmów jak constraint
programming, nawroty itp?

pozdrawiam


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Tue, 8 Nov 2005 14:40:55 +0000 (UTC), " rr"
<rradz@NOSPAM.gazeta.pl> wrote:

>> Co to znaczy "modelowac z wykorzystaniem Prologa"?... Co to znaczy
>> "modelowac" w ogole?..
>
>Chodzi mi o stworzenie schematu/opisu dzia³ania aplikacji. 
>
>> A UML  rzeczywiscie sie nir nadaje do niczego.
>
>Dlaczego do niczego? Poza tym, mo¿e OCL Waszym zdaniem bêdzie stosunkowo
>wystarczaj±cy do opisywania (modelowania) takich mechanizmów jak constraint
>programming, nawroty itp?
>

Przeparszam, ale nei rozumiem o co ci chodzi. Prawdopodobnie dlatego
ze ty tez nie rozumiesz.

OCL tez do niczego sie nie nadaje. Nijakich nawrotow w nim nie ma.

A.L.

On Tue, 8 Nov 2005 14:40:55 +0000 (UTC), " rr"
<rradz@NOSPAM.gazeta.pl> wrote:

>> Co to znaczy "modelowac z wykorzystaniem Prologa"?... Co to znaczy
>> "modelowac" w ogole?..
>
>Chodzi mi o stworzenie schematu/opisu dzia³ania aplikacji. 
>
>> A UML  rzeczywiscie sie nir nadaje do niczego.
>
>Dlaczego do niczego? Poza tym, mo¿e OCL Waszym zdaniem bêdzie stosunkowo
>wystarczaj±cy do opisywania (modelowania) takich mechanizmów jak constraint
>programming, nawroty itp?
>
>pozdrawiam


Zobacz to:

http://citeseer.ist.psu.edu/fischer00combination.html

i ogolnie o notacji zwanej "Z" i "Object -Z". To jest to czego ja
uzywam do specyfikacji "constraint programming". Do "consurrent
systems" uzywam notacji zwanej CSP

Patrz tez:

http://www.itee.uq.edu.au/~smith/objectz.html
http://www.afm.sbu.ac.uk/z/

Tutaj jest ksaizka free

http://spivey.oriel.ox.ac.uk/~mike/zrm/

i tutaj

http://www.zuser.org/zbook/


A.L.

> OCL tez do niczego sie nie nadaje. Nijakich nawrotow w nim nie ma.

Chodzi mi o analogiczne do UML/OCL narzędzie pozwalające na modelowanie CLP i
współbieżności. Być może nie wyraziłem się precyzjnie co do narzędzia, ale
gdybym znał narzędzie "o jakie mi chodzi", to bym o nie nie pytał ;)

Wiem że OCL nie definiuje działań podejmowanych w przypadku niespełnienia
niezmienników klas lub warunków początkowych, czy końcowych - ale można w nim
modelować ograniczenia. Niektórzy twierdzą że w OCL można doskonale modelować
CLP, współbieżność itp stąd pytam co o tym sądzicie... No i jeśli się nie
nadaje, to czy jest do wyboru coś innego.

Dzięki za pomoc!

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> Tutaj jest ksaizka free
> 
> http://spivey.oriel.ox.ac.uk/~mike/zrm/
> 
> i tutaj
> 
> http://www.zuser.org/zbook/

Super :) Wielkie dzięki.


Pozdrawiam

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Tue, 8 Nov 2005 16:25:46 +0000 (UTC), " rr"
<rradz.SKASUJ@gazeta.pl> wrote:

>
>> OCL tez do niczego sie nie nadaje. Nijakich nawrotow w nim nie ma.
>
>Chodzi mi o analogiczne do UML/OCL narzêdzie pozwalaj±ce na modelowanie CLP i
>wspó³bie¿no¶ci. Byæ mo¿e nie wyrazi³em siê precyzjnie co do narzêdzia, ale
>gdybym zna³ narzêdzie "o jakie mi chodzi", to bym o nie nie pyta³ ;)
>

Jak napisalem w innym poscie, do modelowania procesow wspolbieznych
uztawam CSP (Communicating Sequentail Processes) a implementuje je w
Jave poslugujac sie biblioteka JCSP

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Jest sporo pisanych materialow na temat formalizmu CSP, w
szczegolnosci ksiazka Hoare

http://www.usingcsp.com/cspbook.pdf

Innych nie mam pod reka, moge podac tytuly pozniej jak cie
zainteersuje. Praca doktorska ktora ci podalem w poprzednim poscie
dotyczy z grubsza polaczenia notacji CSP i Object-Z


>Wiem ¿e OCL nie definiuje dzia³añ podejmowanych w przypadku niespe³nienia
>niezmienników klas lub warunków pocz±tkowych, czy koñcowych - ale mo¿na w nim
>modelowaæ ograniczenia. Niektórzy twierdz± ¿e w OCL mo¿na doskonale modelowaæ
>CLP, wspó³bie¿no¶æ itp st±d pytam co o tym s±dzicie... 

Sadzimy ze opowiadaja glupoty.

Inna notacja ktora wydaje sie godna polecenai to notacja BON (Business
Obejct Notation) 

http://ebon.sourceforge.net/

jest ksaizka na ten temat ktora mozna sciagnac stad

http://www.bon-method.com/index_normal.htm

Niestety, mam raczej niweielkie doswiadczenie praktyczne z BON, ale to
co mam wyglada zachecajaco.


A.L.

"rr" <rradz@WYTNIJ.gazeta.pl> wrote:

> Spotkalem sie ostatnio z opiniami (nie wiem na ile slusznymi, bo nie
> jestem specem od OOP i UML'a, stad Was pytam) ze UML dobry
> jest moze do samego OOP

Moje doswiadczenia z UMLem nie sa zbyt pozytywne. Spotkalem sie wprawdzie z 
przypadkami niewielkich projektow stosujacych okrojony UML ze wzglednym 
powodzeniem, nie mialem jednak okazji doswiadczyc tego samego przy 
projektach wiekszych rozmiarow. Jesli ktos ma inne obserwacje poparte 
praktyka, chetnie poslucham.

Robert Perlinski 

A.L. <lewando_won_@kalabambuko.com> writes:

[...]

> Jak napisalem w innym poscie, do modelowania procesow wspolbieznych
> uztawam CSP (Communicating Sequentail Processes) a implementuje 
> je w Jave poslugujac sie biblioteka JCSP
>
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Toto ma implementację?  Ja zawsze myślałem, że CSP to tylko
teoretyczny formalizm.

A.L. <lewando_won_@kalabambuko.com> writes:

[...]

> i ogolnie o notacji zwanej "Z" 

Dla uzupełnienia dodam, że istnieje jeszcze notacja nazywana 'B'.
Opis na przykład http://www.b-core.com.

On Tue, 08 Nov 2005 18:07:35 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>A.L. <lewando_won_@kalabambuko.com> writes:
>
>[...]
>
>> Jak napisalem w innym poscie, do modelowania procesow wspolbieznych
>> uztawam CSP (Communicating Sequentail Processes) a implementuje 
>> je w Jave poslugujac sie biblioteka JCSP
>>
>> http://www.cs.kent.ac.uk/projects/ofa/jcsp/
>
>Toto ma implementacjê?  Ja zawsze my¶la³em, ¿e CSP to tylko
>teoretyczny formalizm.

Co weicej, implementacja jest ZNAKOMITA. Zreszta, nie jedyna, jest
jeszcze jedna. W aplikacji w ktorej to-to uzywam jest cos ze 200
procesow i 800 kanalow. Neich ktos sproboje cos takiego napisac bez
JCSP...

Zreszta, JCSP ma swoje "tyly" tez. Dosyc trudno debugowac takic
rzeczy, i latwo sie zapedzic w "kozi rog" nei robiac dostatecznie
dokladnego projektu. Nieststy, toole do weyfikacji nei sa dostepne pod
WIndows... latwo tez popasc w syndrom "spaghetti channels"... Ale poki
co, nei widze lepszej metody pisania aplikacji wspolbieznych pod Jave.

Jest wersja komercyjna (dosyc droga) w ktorej  a) kanaly moga
przesylac przez network, b) jest pre-processor CSP ktory umozliwia
wstawianie konstrukcji CSP w kod Javy.

A.L.

Dnia Tue, 08 Nov 2005 07:39:08 -0600, A.L. skrobie:
> A UML  rzeczywiscie sie nir nadaje do niczego.

Może jednak? ;)

Z moich obserwacji jak na razie wynika, że UML może być dobry do
dokumentowania, czy też mówiąc bardziej chamsko, "wspomagania wyobraźni".
Natomiast dla mnie to beznadziejnie wygląda, jeśli z obrazków miałby być
generowany kod (do generatorów kodu mam zresztą uraz i tak).

Jakie w ogóle "sensowne" metody podejścia do projektowania (poza już
wspomnianymi) są warte uwagi?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

> Natomiast dla mnie to beznadziejnie wygląda, jeśli z obrazków miałby
> być generowany kod (do generatorów kodu mam zresztą uraz i tak).

Nie z obrazków, a z diagramów.  W elektronice też masz taki VHDL 
i diagramy.  Ja nadal jestem zdania, że gdyby to było dobrze zrobione,
to generowanie szkieletu kodu z diagramu ma sens.

Dnia Tue, 08 Nov 2005 22:13:04 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> [...]

> > Natomiast dla mnie to beznadziejnie wygląda, jeśli z obrazków miałby
> > być generowany kod (do generatorów kodu mam zresztą uraz i tak).

> Nie z obrazków, a z diagramów.

Ojej, ale różnica.

> W elektronice też masz taki VHDL i diagramy.

Ale ty nie porównuj projektowania układów i projektowania oprogramowania!
Stopień skomplikowania tych rzeczy różni się o ładnych kilka rzędów. Co prawda
wynika to głównie z fakty, że dziś elektronika ma być uniwersalna i robić
potencjalnie bardzo dużo, a poza tym jak najwięcej funkcjonalności zwala się
na oprogramowanie - ale to nie zmienia faktu.

> Ja nadal jestem zdania, że gdyby to było dobrze zrobione,
> to generowanie szkieletu kodu z diagramu ma sens.

Szkieletu owszem. Ewentualnie dobrze by było, żeby narzędzie umiało dokonywać
SELEKTYWNYCH zmian w kodzie źródłowym, związanym z tym, co to narzędzie akurat
interesuje. A reszta dowolnie modyfikowana przez użytkownika.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Robert Perlinski napisał(a):
> "rr" <rradz@WYTNIJ.gazeta.pl> wrote:
> 
> 
>>Spotkalem sie ostatnio z opiniami (nie wiem na ile slusznymi, bo nie
>>jestem specem od OOP i UML'a, stad Was pytam) ze UML dobry
>>jest moze do samego OOP
> 
> 
> Moje doswiadczenia z UMLem nie sa zbyt pozytywne. Spotkalem sie wprawdzie z 
> przypadkami niewielkich projektow stosujacych okrojony UML ze wzglednym 
> powodzeniem, nie mialem jednak okazji doswiadczyc tego samego przy 
> projektach wiekszych rozmiarow. Jesli ktos ma inne obserwacje poparte 
> praktyka, chetnie poslucham.
> 
> Robert Perlinski 
> 
> 
Ja od czasu do czasu używam UMLa do komunikacji w zespole - jednak tylko 
na zasadzie diagramów jednorazowego użytku, wyrzucanych po spełnieniu 
swojej misji. Próby z narzędziami CASE generującymi kod, modele z kodu, 
lub nawet w obie strony zakończyły się fiaskiem, głównie z powodu 
nieporęczności tych aplikacji - trzeba spędzać zbyt dużo czasu nad ich 
obsługą.

Moje ostatnie odkrycie - i to dla mnie przebój - to banalnie prosty 
programik UMLet, w którym diagramy tworzy się nieporównanie szybciej, 
niż w jakimkolwiek innym narzędziu. UMLet osiąga to dzięki innowacyjnemu 
sposobowi edycji elementów diagramu, przypominającemu edycję stron wiki.
Odpada żmudne klikanie w każdy atrybut/operację, a zamiast tego 
wprowadza się wszystkie składniki klasy w specjalnym formacie w okienku 
tekstowym.
Za pomocą edycji tekstu można nawet zbudować (i to błyskawicznie) cały 
diagram sekwencji.

A w ogóle, to bardzo polecam lekturę http://www.agilemodeling.com/

Przemyslaw Pokrywka

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

>> Ja nadal jestem zdania, że gdyby to było dobrze zrobione,
>> to generowanie szkieletu kodu z diagramu ma sens.
>
> Szkieletu owszem. Ewentualnie dobrze by było, żeby narzędzie umiało
> dokonywać SELEKTYWNYCH zmian w kodzie źródłowym, związanym z tym, 
> co to narzędzie akurat interesuje. A reszta dowolnie modyfikowana 
> przez użytkownika.

Yup.  No i podstawa: żeby cały czas była utrzymywana spójność
kod-diagram.  Tzn. definiowanie klas w kodzie musiałoby od razu
dodawać klasy w bazie danych projektu, tak, żeby je było można 
dołączyć do diagramu.  Nie widziałem jeszcze takiego narzędzia.

-- 
http://www.piotr.dembiński.prv.pl

> Moje doswiadczenia z UMLem nie sa zbyt pozytywne. Spotkalem sie wprawdzie z 
> przypadkami niewielkich projektow stosujacych okrojony UML ze wzglednym 
> powodzeniem, nie mialem jednak okazji doswiadczyc tego samego przy 
> projektach wiekszych rozmiarow.

Dziwne. Wiem jak funkcjonuje kilka dużych projektów w Prokomie i Softbanku i 
używają tam UMLa (zasadniczo króluje RUP). Czego w takim razie używają w Twojej 
firmie przy dużych projektach? Pytam, bo ciekaw jestem jaka jest sensowna,
dobrze wspierana i zaimplementowana alternatywa.

pozdrawiam

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:

> Yup.  No i podstawa: żeby cały czas była utrzymywana spójność
> kod-diagram.

I to jest glowny problem :)

AK

"Karpierz, Adam" <adam_karpierz@NOOOSPAAMmentor.com> writes:

> ""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:
>
>> Yup.  No i podstawa: żeby cały czas była utrzymywana spójność
>> kod-diagram.
>
> I to jest glowny problem :)

Jak są np. zaawansowane środowiska typu IntelliSense, to jaki problem
z zapewnieniem spójności kod-diagram?  IMO podstawowy problem jest
taki, że programiści są nauczeni myśleć tekstem, a tu trzeba jeszcze
umieć myśleć diagramami.

On Wed, 09 Nov 2005 16:13:21 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>"Karpierz, Adam" <adam_karpierz@NOOOSPAAMmentor.com> writes:
>
>> ""Piotr Dembiñski"" <pdemb@gazeta.pl> wrote:
>>
>>> Yup.  No i podstawa: ¿eby ca³y czas by³a utrzymywana spójno¶æ
>>> kod-diagram.
>>
>> I to jest glowny problem :)
>
>Jak s± np. zaawansowane ¶rodowiska typu IntelliSense, to jaki problem
>z zapewnieniem spójno¶ci kod-diagram?  IMO podstawowy problem jest
>taki, ¿e programi¶ci s± nauczeni my¶leæ tekstem, a tu trzeba jeszcze
>umieæ my¶leæ diagramami.

Kolego, poczejakmy tak z 5 lat i zobaczny czy Kolegi opinia bedzie
taka sama czy zmeini sie neico.

A.L.

A.L. <lewando_won_@kalabambuko.com> writes:

[...]

> Kolego, poczejakmy tak z 5 lat i zobaczny czy Kolegi opinia bedzie
> taka sama czy zmeini sie neico.

Opinia o tym, że trzeba umieć myśleć na wiele sposobów?  Raczej nie :)

Piotr Dembiński napisał(a):
> A.L. <lewando_won_@kalabambuko.com> writes:
> 
> [...]
> 
> 
>>Kolego, poczejakmy tak z 5 lat i zobaczny czy Kolegi opinia bedzie
>>taka sama czy zmeini sie neico.
> 
> 
> Opinia o tym, że trzeba umieć myśleć na wiele sposobów?  Raczej nie :)
Od programisty wymaga się, aby oddał działający kod w określonym 
terminie. Kod, a nie diagram. Jest tak dlatego, iż klient kupuje kod 
(być może skompilowany) a nie diagram. I nie ma w tym nic sprzecznego z 
myśleniem na wiele sposobów dopóki kod jest oddawany w terminie.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

" rr" <rradz@NOSPAM.gazeta.pl> wrote:

>> Moje doswiadczenia z UMLem nie sa zbyt pozytywne.
>> [...]

> Dziwne. Wiem jak funkcjonuje kilka dużych projektów w Prokomie i
> Softbanku i uzywaja tam UMLa (zasadniczo kroluje RUP). Czego
> w takim razie uzywaja w Twojej firmie przy duzych projektach? Pytam,
> bo ciekaw jestem jaka jest sensowna, dobrze wspierana
> i zaimplementowana alternatywa.

W naszy wypadku UML jest uzywany jedynie na poziomie "coarse-grained 
components", lub innymy slowy do pokazania interakcji i przeplywu danych w 
makro-skali. Prawie nigdy jednak nie schodzimy z tym do poziomu kodu. 
Dlaczego? Przynajmniej kilka przyczyn:

1. Trudna do uzyskania *w praktyce* sychronizacja kodu z "obrazkami"

2. Brak dobrych narzedzi, ktore umozliwiaja nie tylko plynna integracje kodu 
z UMLem, ale rowniez wplywanie na to jak ten proces przebiega. To co bowiem 
znane mi narzedzia generuja np. w przypadku portlets, jsps, ejbs (itp. itd - 
dluga lista) nie nadaje sie praktycznie do niczego. Dodam tylko, ze naszym 
standardem narzedziowym jest "RAD for Websphere" (IBM/Rational), ktory 
technicznie rzecz biorac jest przyczepka do Eclipse.

3. Generalny problem z tym, ze idea zawarta w powiedzenu "picture is worth a 
thousand words" traci nieco na atrakcyjnosci w przypadku kiedy "slow" jest 
nieco wiecej...

Robert Perlinski 

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

> Piotr Dembiński napisał(a):
>> A.L. <lewando_won_@kalabambuko.com> writes:
>> [...]
>>
>>>Kolego, poczejakmy tak z 5 lat i zobaczny czy Kolegi opinia bedzie
>>>taka sama czy zmeini sie neico.
>> Opinia o tym, że trzeba umieć myśleć na wiele sposobów?  
>> Raczej nie :)
> Od programisty wymaga się, aby oddał działający kod w określonym
> terminie. Kod, a nie diagram. Jest tak dlatego, iż klient kupuje 
> kod (być może skompilowany) a nie diagram. 

Ofkors.  Poza tym ktoś musi jeszcze pozbierać wymagania.

Piotr Dembiński wrote:

> Yup.  No i podstawa: żeby cały czas była utrzymywana spójność
> kod-diagram.  Tzn. definiowanie klas w kodzie musiałoby od razu
> dodawać klasy w bazie danych projektu, tak, żeby je było można 
> dołączyć do diagramu.  Nie widziałem jeszcze takiego narzędzia.

Takie rzeczy to robił Together ByleJakiEdition w roku gdzieś 2000 bez 
problemów.
Z tym, że tak naprawde to nie jest żaden specjalny ficzer. Z 
generowaniem kodu, MDA, UMLem etc. to ma mało wspólnego. Ot ficzer do IDE.
W chwili obecnej podobną funkcjonalność zapewniają w każdym głupim 
środowisku drzewka/explorery klas (i okazuje się, że to często wystarcza).

-- 
jarekr

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> 
> 
>>Piotr Dembiński napisał(a):
>>
>>>A.L. <lewando_won_@kalabambuko.com> writes:
>>>[...]
>>>
>>>
>>>>Kolego, poczejakmy tak z 5 lat i zobaczny czy Kolegi opinia bedzie
>>>>taka sama czy zmeini sie neico.
>>>
>>>Opinia o tym, że trzeba umieć myśleć na wiele sposobów?  
>>>Raczej nie :)
>>
>>Od programisty wymaga się, aby oddał działający kod w określonym
>>terminie. Kod, a nie diagram. Jest tak dlatego, iż klient kupuje 
>>kod (być może skompilowany) a nie diagram. 
> 
> 
> Ofkors.  Poza tym ktoś musi jeszcze pozbierać wymagania.
Jak programista siada do pisania kodu, to wymagania już są pozbierane. 
AL wyciął część Twojej wypowiedzi ważną dla mnie w tym kontekście
<cyt>
Jak są np. zaawansowane środowiska typu IntelliSense, to jaki problem
z zapewnieniem spójności kod-diagram?  IMO podstawowy problem jest
taki, że programiści są nauczeni myśleć tekstem, a tu trzeba jeszcze
umieć myśleć diagramami.
</cyt>
Zgadzam się, że diagramy można stosować, ale na innych etapach niż 
kodowanie. A jeżeli uważasz, że można programować kodem i diagramami, to 
powiedz, jakiego narzędzia używasz.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Grzesiek G. wrote:

> Zgadzam się, że diagramy można stosować, ale na innych etapach niż 
> kodowanie. A jeżeli uważasz, że można programować kodem i diagramami, to 
> powiedz, jakiego narzędzia używasz.

Pewnie JBuilder, Eclipse i insze. Integracja diagramu klas z kodem nie 
jest problemem. Tylko w zaawansowanych IDE niewiele też pomaga.
-- 
jarekr

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

> Zgadzam się, że diagramy można stosować, ale na innych etapach 
> niż kodowanie. A jeżeli uważasz, że można programować kodem 
> i diagramami, to powiedz, jakiego narzędzia używasz.

Nie jestem aktywny zawodowo.  Kiedyś korzystałem z Emacsa do pisania 
i programiku Dia do rysowania wykresów.

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> 
> [...]
> 
> 
>>Zgadzam się, że diagramy można stosować, ale na innych etapach 
>>niż kodowanie. A jeżeli uważasz, że można programować kodem 
>>i diagramami, to powiedz, jakiego narzędzia używasz.
> 
> 
> Nie jestem aktywny zawodowo.  Kiedyś korzystałem z Emacsa do pisania 
> i programiku Dia do rysowania wykresów.
Ale czy jest to taki tandem, że zmieniasz albo kod, albo diagram, 
włączasz synchronizację i kod staje się tożsamy z diagramem? Czy nad 
diagramem mogą pracować 2 osoby jednocześnie?
O ile pamiętam Dia sprzed 2 lat, to była to zabawka (czasami bardzo 
pomocna w pracy, jak i Paintowi się zdarza).

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

> Piotr Dembiński napisał(a):
>> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
>> [...]
>>
>>> Zgadzam się, że diagramy można stosować, ale na innych etapach niż
>>> kodowanie. A jeżeli uważasz, że można programować kodem 
>>> i diagramami, to powiedz, jakiego narzędzia używasz.
>> Nie jestem aktywny zawodowo.  Kiedyś korzystałem z Emacsa 
>> do pisania i programiku Dia do rysowania wykresów.
> Ale czy jest to taki tandem, że zmieniasz albo kod, albo diagram,
> włączasz synchronizację i kod staje się tożsamy z diagramem? 

No nie.  Ja tylko tu gdybam, że taka synchronizacja byłaby fajna.

> Czy nad diagramem mogą pracować 2 osoby jednocześnie?

Myślę, że w tym samym stopniu, co nad jednym plikiem z kodem.

> O ile pamiętam Dia sprzed 2 lat, to była to zabawka (czasami bardzo
> pomocna w pracy, jak i Paintowi się zdarza).

Dokładnie.  Teraz trochę eksperymentuję z Poseidonem.

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
[...]
>>Czy nad diagramem mogą pracować 2 osoby jednocześnie?
> 
> 
> Myślę, że w tym samym stopniu, co nad jednym plikiem z kodem.
> 
Nie wyraziłem się ściśle - mówiąc diagram miałem na myśli ich zbiór jako 
projekt. Zatem pytanie miało być: czy mogą 2 osoby pracować nad takim 
projektem.

A jeżeli chodzi o plik z kodem - mogą 2 programiści pracować nad jednym 
plikiem. Niestety, koszt synchronizacji ich zmian przeważnie czyni tę 
pracę nieefektywną.

[...]

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

> Piotr Dembiński napisał(a):
>> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> [...]
>>>Czy nad diagramem mogą pracować 2 osoby jednocześnie?
>> Myślę, że w tym samym stopniu, co nad jednym plikiem z kodem.
>>
> Nie wyraziłem się ściśle - mówiąc diagram miałem na myśli ich zbiór
> jako projekt. Zatem pytanie miało być: czy mogą 2 osoby pracować nad
> takim projektem.

No to chyba też tak samo jak z kodem.

> A jeżeli chodzi o plik z kodem - mogą 2 programiści pracować nad
> jednym plikiem. Niestety, koszt synchronizacji ich zmian przeważnie
> czyni tę pracę nieefektywną.

To jest chyba tak, jak z teorią X i teorią Y w zarządzaniu -- 
jedni chcą wspólnej własności kodu (XP), inni wolą dokładnie 
określone granice kompetencji.

-- 
http://www.piotr.dembiński.prv.pl