Hello world w UML... (+ C++)
Krzys
Czy ktos z was zna moze link do pelnego przykladu projetkowania oprogramowania
z uzyciem UML ? (badz moze to zaprezentowac takowe).
Postaram sie powiedziec w kilku slowach o co mi chodzi. Z reguly gdy ktos uczy
sie jezyka programowania przechodzi przez faze czegos co mozna nazwac "Hello
world!". Na tak prostym przykladzie uczy sie, ze #include <stdio.h> dodaje
jakas tam biblioteke, jak wyglada generalnie konstrukca programu, uczy sie
uzycia jakiejs funkcji z dolaczonej biblioteki (printf) i w koncu kompiluje
program i moze zobaczyc ze to dziala !
Czy ktos zna taki przyklad powiazania C++ z UML ?? Moze byc banalnie prosty
ale zeby byl kompletny. Generalnie czytam o UML i ... fajnie jest. Duzo
roznych fajnych rzeczy - use casy, niesamowicie cudowne diagramy i inne...
Ale po co to wszystko ????
Czesto do roznych diagramow uzywane sa rozne przyklady (takie ktore akurat tam
pasuja) i nijak nie widac calosci.
Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
/Krzysiek
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
A.L.
<zhang_guo...@gazeta.pl> wrote:
>Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
>chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
>jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
Bo to sa cegly. I nie prowadza do niczego.
A.L.
Krzysiek
> >chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
> >jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
>
> Bo to sa cegly. I nie prowadza do niczego.
>
> A.L.
Dzieki za pomoc.. Nie trzeba bylo.
Wiem, ze czesto denerwujace i totalnie nie na miejscu sa pytania ludzi o
broszurke, z ktorej moglbym/moglabym sie nauczyc danego jezyka programowania,
bo takie cos jest niemozliwe i zawsze trzeba przebranac przez kilka ksiazek,
jeszcze wiecej przykladow itp. itd.
Aczkolwiek, zeby sie zainteresowac dana dziedzina i zaczac w niej drazyc
zawsze znajdzie sie jakis prosty (czyt. pokazowy) przyklad zastosowania danego
zagadnienia. (a potem jest czas na wgryzanie sie w temat)
Ale widac mialem pecha.. Na "dzien dobry" trafilem na osobe, ktora najpierw
przeczytala dziesiec 800 stronicowych ksiazek o programowaniu w jakims tam
jezyku (aczkolwiek jeszcze nie byla gotowa..), trzeba by bylo tu jeszcze
zrozumiec jak jezyki programowania w ogole moga dzialac - tak wiec krotkie
studia nad lingwistyka matematyczna... Potem jeszcze podstawy elektroniki..
(tak zeby nie bylo za latwo i zeby wiedziec jak to wszystko dziala) i
ostatecznie po (prawdopodobnie) wielu latach ciezkich studiow na ekranie
monitora pojawilo sie upragnione:
Hello world!
Gratuluje!!!
A.L.
<zhang_guo...@gazeta.pl> wrote:
>> >Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
>> >chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
>> >jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
>>
>> Bo to sa cegly. I nie prowadza do niczego.
>>
>> A.L.
>
>Dzieki za pomoc.. Nie trzeba bylo.
>
>Wiem, ze czesto denerwujace i totalnie nie na miejscu sa pytania ludzi o
>broszurke, z ktorej moglbym/moglabym sie nauczyc danego jezyka programowania,
>bo takie cos jest niemozliwe i zawsze trzeba przebranac przez kilka ksiazek,
>jeszcze wiecej przykladow itp. itd.
Nieprawda.
>Aczkolwiek, zeby sie zainteresowac dana dziedzina i zaczac w niej drazyc
>zawsze znajdzie sie jakis prosty (czyt. pokazowy) przyklad zastosowania danego
>zagadnienia. (a potem jest czas na wgryzanie sie w temat)
>
Ale akurat jezykow programowania nie da sie uczyc "na
przykladzie"... Przynajmniej niektorych aspektow sie nei da.
>Ale widac mialem pecha.. Na "dzien dobry" trafilem na osobe, ktora najpierw
>przeczytala dziesiec 800 stronicowych ksiazek o programowaniu w jakims tam
>jezyku (aczkolwiek jeszcze nie byla gotowa..), trzeba by bylo tu jeszcze
>zrozumiec jak jezyki programowania w ogole moga dzialac - tak wiec krotkie
>studia nad lingwistyka matematyczna... Potem jeszcze podstawy elektroniki..
>(tak zeby nie bylo za latwo i zeby wiedziec jak to wszystko dziala) i
>ostatecznie po (prawdopodobnie) wielu latach ciezkich studiow na ekranie
>monitora pojawilo sie upragnione:
>Hello world!
>
>Gratuluje!!!
Gratulujesz czego? Ja napisalem nie wprost ze uwazam ze a) wszystkie
ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
kasy autorom, b) UML jako taki jest g.... warty.
A.L.
Krzysiek
> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
> kasy autorom, b) UML jako taki jest g.... warty.
>
> A.L.
Jesli UML jest g..... warty, to co nie jest ? Jakie rozwiazania polecasz ?
A co do ksiazek.. no coz.. z nimi zle, bez nich tez niedobrze. Sa lepsze i
gorsze - ale generalnie dobrze, ze sa :-)
/Krzysiek
Damian 'legion' Szuberski
>>Gratuluje!!!
> Gratulujesz czego? Ja napisalem nie wprost ze uwazam ze a) wszystkie
> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
> kasy autorom, b) UML jako taki jest g.... warty.
--
Damian Szuberski
A.L.
<zhang_guo...@gazeta.pl> wrote:
>>Ja napisalem nie wprost ze uwazam ze a) wszystkie
>> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
>> kasy autorom, b) UML jako taki jest g.... warty.
>>
>> A.L.
>
>Jesli UML jest g..... warty, to co nie jest ? Jakie rozwiazania polecasz ?
>
>A co do ksiazek.. no coz.. z nimi zle, bez nich tez niedobrze. Sa lepsze i
>gorsze - ale generalnie dobrze, ze sa :-)
>
Uzywam BON - Busines Object Notation: "Seam;ess Obejct-Oriented
Software Architecture: Analysis and Design of Reliable Systems", Kim
Wallden, & Jean-Marc Nerson, Prentice Hall, 1995. BON bazuje na
jezyku programwoania a nie obrazkach (chociaz obrazki mzoan uzyc do
ilustracji), albowiem jezyk programowwania jest jedynym jezykiem
ktory jest dostatecznie ekspresywny i precyzyjny zeby opisac systemy
ktoer sa bardziej zlozone niz "database front end".
Detale mozna znalezc tutaj
http://www.bon-method.com/index_normal.htm
tamze do sciagniecia ksiazka o ktorej pisze powyzej.
Natomiast jak juz musisz UML, to polecam ksiazke "UML Distilled: A
Brief Guide to the Standard Object Modeling Language", Martin
Fowler, Addison Wesley 2003. Wydanie ktore mam na polce nosi dumny
napis "Third Edition", ale chyba to nie jest wydanei ostatnie.
Ksiazka ma tylko 160 stron i objasnia szybko i dokladnie czym UML
jest a czym nie jest.
Polecam etz "UNL in a Nutshell: A Desktop Quick Reference", Sinan Si
Albir, O'Reilly 1998, ale na pewno nowsze wydania sa.
Zupelnei zas najlepsza to "UML Pocket Reference",
http://www.oreilly.com/catalog/uml2pr/
136 stron. 0 36 za duzo.
Natomiast ksziaki "gurus" wypada miec na polce tak jak Encyclopedia
Britannica - zeby zadziwic Krewnych i Znajomych. Ale w zadnym
wypadku nei czytac
A.L.
A.L.
O uzasadnienei nalzey zapytac autorow. Moze cos meili na mysli...
A.L.
A.L.
wrote:
>Uzywam BON - Busines Object Notation: "Seam;ess Obejct-Oriented
>Software Architecture: Analysis and Design of Reliable Systems"
Zapomnialem dopisac... Uzywam tez nagminnie notacji zwanej Z i
Object-Z oraz CSP-Z
A.L.
Piotr Dembiński
Damian 'legion' Szuberski
>>> kasy autorom, b) UML jako taki jest g.... warty.
>>Co do b) istnieje jakieś sensowne uzasadnienie?
> O uzasadnienei nalzey zapytac autorow. Moze cos meili na mysli...
--
Damian Szuberski
A.L.
Albowiem nei jest ani uniwersalny ani nie jest jezykiem.
Dyskusja na ten temat toczyla sie na tej grupie periodyccznie przez
ostatnie 6 lat. Proponuje zajzrec do googli. Nie chce mi sie
powtarzac argumentow.
A.L.
Krzysiek
> chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
> jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
>
> /Krzysiek
Abstrahujac od toczacej sie dyskusji o tym, ktore narzedzie jest lepsze/gorsze
od tego gorszego/lepszego czy znajdzie sie ktos kto da mi przyklad stosowania
owych narzedzi w projektowaniu aplikacji tak.. "od pomyslu do przemyslu" ?
Z jednej strony rozumiem, ze stoswanie tak.. "poteznych" narzedzi do
malutkich, pokazowych projekcikow moze mijac sie z celem, ale z drugiej strony
ciezko mi uwiezyc, ze ktos kto nie ma w ogole doswiadczenia czy to z UML czy z
innym narzedziem od razu jest rzucany na gleboka wode i tak bez zadnego
doswiadczenia od razu projektuje i realizuje potezne aplikacje.
Pytam sie na grupie, gdyz nie udalo mi sie znalezc na googlach konkretnego,
rzeczywistego przykladu. Ciagle tylko jakies wydumane kawalki projektow, gdzie
nastepny krok w projektowaniu nijak sie nie ma do poprzedniego (juz nie mowiac
jak z tego mialby powstac kiedys realny kod i dzialajacy system).
Pozdrawiam,
Maciej Sobczak
> UML jako taki jest g.... warty.
UML jako taki (czyli oderwany od konkretnego języka programowania) jest
OK, natomiast z mojego punktu widzenia problemem jest to, że większość
jego propagatorów (i w rezultacie większość jego użytkowników) skupia
się na jego wykorzytaniu w trybie "jeden prostokącik <-> jedna
niskopoziomowa konstrukcja w kodzie źródłowym danego języka".
To faktycznie jest słabe.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Seweryn Habdank-Wojewódzki
Maciej Sobczak napisał(a):
> A.L. wrote:
>
> > UML jako taki jest g.... warty.
Tak ostro się nie wypowiadam, ale ten trend potrzymuję, bo ... (patrz
dalej)
> UML jako taki (czyli oderwany od konkretnego języka programowania) jest
> OK, natomiast z mojego punktu widzenia problemem jest to, że większość
> jego propagatorów (i w rezultacie większość jego użytkowników) skupia
> się na jego wykorzytaniu w trybie "jeden prostokącik <-> jedna
> niskopoziomowa konstrukcja w kodzie źródłowym danego języka".
> To faktycznie jest słabe.
Dodam, że jest wiele konstrukcji programistycznych związanych z
projektem klas,
których nie ma szans zapisać w UML. To powoduje, że np. genratory
kodu oparte o
schematy UML generują nie efektywny kod, albo go nie są wstanie
wygenerować.
Albo schemat narysowany nie jest efektywnie wykorzystany, ostatecznie
np. nie
ma zaznaczonych istotnych związków pomiędzy klasami, które są
istotne z punktu
widzenia programisty posługującego się schematem UML.
Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
nie będzie
można efektywnie rysunku wykorzystać.
Pozdrawiam.
Maciej Sobczak
> Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
> nie będzie
> można efektywnie rysunku wykorzystać.
Bez przesady. Eksportujesz UML do XMI (jeśli dane narzędzie tego nie
umie, to je spuść z wodą) i zapinasz pasy.
Jak już pisałem, problemem jest zbytnie przywiązanie się do prostego
mapowania UML na niskopoziomowe konstrukcje jakiegoś języka. Jeśli
tekstowe wyklepanie klasy z kilkoma deklaracjami metod zajmuje mi
kilkadziesiąt sekund i tyle samo zajmuje mi wyklikanie prostokącika na
ekranie z sygnaturami tych samych metod, to zysku z zamiany edytora
tekstu na program rysunkowy nie ma żadnego. Ale jeśli jesteś w stanie
wykorzystać model (np. XMI) do generacji kodu na wyższym poziomie
złożoności, to reszta jest ograniczona tylko Twoją wyobraźnią. UML jest
wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
pokryć całkiem spory kawałek procesu produkcyjnego. Ale nie przy
tradycyjnym, niskopoziomowym mapowaniu "prostokącik <-> klaska".
Oczywiście, wymaga to inwestycji w generatory kodu, ale tam gdzie się to
nie opłaca UML jest zwykle w ogóle do niczego nie potrzebny.
Seweryn Habdank-Wojewódzki
Maciej Sobczak napisał(a):
> Seweryn Habdank-Wojewódzki wrote:
>
> > Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
> > nie będzie
> > można efektywnie rysunku wykorzystać.
>
> Bez przesady. Eksportujesz UML do XMI (jeśli dane narzędzie tego nie
> umie, to je spuść z wodą) i zapinasz pasy.
Nie to miałem na myśli. Oczywiście, że jak masz UML i możesz
przerzucić
to na XMI, a dalej na kod i to jest super.
> Jak już pisałem, problemem jest zbytnie przywiązanie się do prostego
> mapowania UML na niskopoziomowe konstrukcje jakiegoś języka. Jeśli
> tekstowe wyklepanie klasy z kilkoma deklaracjami metod zajmuje mi
> kilkadziesiąt sekund i tyle samo zajmuje mi wyklikanie prostokącika na
> ekranie z sygnaturami tych samych metod, to zysku z zamiany edytora
> tekstu na program rysunkowy nie ma żadnego.
Właśnie.
> Ale jeśli jesteś w stanie
> wykorzystać model (np. XMI) do generacji kodu na wyższym poziomie
> złożoności, to reszta jest ograniczona tylko Twoją wyobraźnią.
Lub możliwościami XMI albo UML.
> UML jest
> wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
> pokryć całkiem spory kawałek procesu produkcyjnego.
Hmm... Jakoś nie dotarłem do tak obszernego kursu UML, czy coś
polecasz?
Kłopot polega na tym jak np. zaznaczyć, żeby genrator stworzył
pewną ilość
specjalizacji szablonu w C++.
W druga stronę ładne rysunki robi doksygen, czyli kiedy mam kod z
szablonami
i masz pewną ilość specjalizacji i konkretyacji, to w wyniku pracy
doxygena masz
do tego rysunek. Czyli doksygen sam znajduje w pewnym sensie pokrycie
klas.
Dzięki temu można sprawdzić jak się ma rzeczywisty kod w stosunku
do UML.
Ale UML nie ma opcji wskazywania na konkretyzacje czy specjalizacje.
A druga sprawa. jak ładnie można pokazać np.: Javowe
class Foo < ? extends Bar >
{}
To jest relatywnie silny kontrakt. I zapis ten dość mocno wpływa na
wygląd klasy
Foo i łączy ją z wyglądem klasy Bar, jaki on by nie był.
Oczywiście z punktu widzenia
konwersji UML -> Kod moge poprostu w << >> wpisać << ? extends Bar >>
i powinien
mi kod powstać dobry, bo generator powinien po prostu przepisać to co
jest w << >>. Ale na rysunku jakby coś ginie. Poza wpiszem w << >> nie
jest odnotowana żadna relacja.
Już nie mówię o C++ konstrukcjach typu:
// -- if construct ------------------------------------------------
// Proposed by Krzysztof Czarnecki and Ulrich Eisenecker
template <bool If, class Then, class Else> struct IF { typedef Then
RET; };
template <class Then, class Else> struct IF<false, Then, Else> {
typedef Else RET;
};
Takie kwiatki w kodzie bardzo wiele potrafią zrobić. I to jest
robione z czasie konpilacji,
czyli to nie sa dynamiczne konstrukcje. To są bardzo silne
zależności pomiędy klasami
i typami. Tego UML nie potrafi "narysować". Zauważ, że relacje
tworzące sie przy użyciu
tego IF powodują związki pomiędzy klasami.
Zauważ, że _nie_ mówię tu o UML jako o sposobie rysowania klas.
Sugeruję, że jest
cienki do zaznaczania związków pomiędzy klasami. Wręcz sugeruję,
że potrafi robić tylko
podstawowe sprawy, takie, które sa statystycznie wykorzystaywane w
średnich
projektach biznesowych.
Nie wspominam tu żadnych skomplikowanych projektów bibliotek, bo UML
przy nich mięknie.
Zobacz jak bardzo różny jest obraz kodu kiedy masz po prostu klasy A,
B a inaczej jest
kiedy gdzieś masz IF < condition , A, B >
Oczywiście moja znajomość UML jest na poziomie UML 2.0. Rozszeżeń
nie znam wiele
albo nie jestem ich świadomy. Tak więc jeśli możesz wskazać na
jakieś opracowania
w których podjęte jest wyzwanie narysowania takich konstrukcji jak
"boost::" to chętnie
poczytam. Narazie jednak moja praca z projektem sprowadza się do
kartki papieru
i ołówka, czasem wspomagam się jakimś programikiem UML, ale w
zasadzie to korzystam
z tego co wypluwa z siebie doxygen. Czasami w kontekście wstecznego
reprojektowania
używam narzędzi typu gcov, aby zaznaczyć związki pomiędzy
obiektami, które nie są jawne,
np. użycie singletonów w klasach.
Pozdrawiam, Seweryn Habdank-Wojewódzki
Maciej Sobczak
>> UML jest
>> wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
>> pokryć całkiem spory kawałek procesu produkcyjnego.
>
> Hmm... Jakoś nie dotarłem do tak obszernego kursu UML, czy coś
> polecasz?
No nie wiem. Cokolwiek - chociaż i tak ostatecznym ograniczeniem będą
możliwości danego programu rysunkowego. Większość z nich jest raczej
sztywna w tym temacie.
> Kłopot polega na tym jak np. zaznaczyć, żeby genrator stworzył
> pewną ilość
> specjalizacji szablonu w C++.
Dobre pytanie. W ogólym podejściu rozwiązaniem może być komentarz
przyczepiony do szablonu, w formacie rozpoznawanym przez generator
(zakładam, że taki komentarz i jego relacja z szablonem będą zaznaczone
w XMI - jeśli nie, to jest problem).
W wersji najbardziej wypasionej program rysunkowy mógłby umożliwiać
rozszerzenie metamodelu UML - wtedy mogłbyś dodać sobie nowe elementy do
składni UML a z drugiej strony nauczyć generator ich obsługi.
Ale nie słyszałem o takich cudach.
(Oczywiście, nie mam na myśli samodzielnego hackowania open-source'owego
programu UML, tylko rozszerzalność metamodelu przewidzianą przez
projektantów tego programu. :-) )
> A druga sprawa. jak ładnie można pokazać np.: Javowe
>
> class Foo < ? extends Bar >
> {}
>
> To jest relatywnie silny kontrakt. I zapis ten dość mocno wpływa na
> wygląd klasy
> Foo i łączy ją z wyglądem klasy Bar, jaki on by nie był.
> Oczywiście z punktu widzenia
> konwersji UML -> Kod moge poprostu w << >> wpisać << ? extends Bar >>
> i powinien
> mi kod powstać dobry, bo generator powinien po prostu przepisać to co
> jest w << >>. Ale na rysunku jakby coś ginie. Poza wpiszem w << >> nie
> jest odnotowana żadna relacja.
Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i
Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.
> Już nie mówię o C++ konstrukcjach typu:
>
> // -- if construct ------------------------------------------------
> // Proposed by Krzysztof Czarnecki and Ulrich Eisenecker
>
> template <bool If, class Then, class Else> struct IF { typedef Then
> RET; };
>
> template <class Then, class Else> struct IF<false, Then, Else> {
> typedef Else RET;
>
> };
>
> Takie kwiatki w kodzie bardzo wiele potrafią zrobić.
A ja bym tego nie modelował w UML tylko raczej potraktował jako element
języka. Obecność czegoś takiego na diagramie kompletnie niczego nie
wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania
relacji pomiędzy tymi typami, które są właściwą domeną dla
analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w
stereotypach albo innych dekoracjach w relacjach pomiędzy tymi
właściwymi typami, zakładając, że IF jest już częścią języka
programowania (dotyczy to wszystkich konstrukcji typu MPL).
Odpowiedni generator potrafiłby taką iluzję stworzyć.
> Tak więc jeśli możesz wskazać na
> jakieś opracowania
> w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> "boost::" to chętnie
> poczytam.
Nie znam żadnych takich opracowań. :-)
Jarosław Żeliński
analizy, modelowanie i opracowanie koncepcji systemu oraz zebranie np.
wymagań na system.
Jeżeli jakieś narzędzie pozwala wyeksportować model w tai sposób, że możliwe
jest wygenerowanie nawet części kodu to mamy dodatkowo zmniejszenie
pracochłonności.
Literatura podaje: dobre i udane projekty IT:
- 50% czasu na analizę i modelowanie
- 30% kodowanie
- 20% testy i oddanie do użytku.
--
--
Jarek
http://jarek.zelinski.biz.pl/
Użytkownik "Maciej Sobczak" <no....@no.spam.com> napisał w wiadomości
news:egvfml$4nf$1...@cernne03.cern.ch...
Seweryn Habdank-Wojewódzki
Maciej Sobczak napisał(a):
> Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i
> Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.
Poproszę o przykład może być na priv.
> A ja bym tego nie modelował w UML tylko raczej potraktował jako element
> języka.
To nie chodzi tyle o język, bo gdyby w innym było to możliwe to też
byłoby dobrze.
Np. ciekawe są klasy w których możesz w runtime lub w czasie
kompilacji
rozszeżać ilośc metod. I tego też się nie da zobrazować.
Krótko mówiąc. UML staje się nażędziem, które przy pewnym
poziomie abstrakcji
jest tylko kulą u nogi, bo nie da się narysować tego co jest
ciężkie. Z rzeczy proste
są proste.
Oczywiście rozumiem i cały czas podkreślam, że np. projekty
biznesowe są
wystarczająco proste strukturalnie, aby stosować UML. Mam nawet
informacje z
wiarygodnego zródła, że w Javie można wiele napisać tyko rysując
i kożystając
z gotowych beanów, to jest programowanie przez rysowanie :-).
> Obecność czegoś takiego na diagramie kompletnie niczego nie
> wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania
> relacji pomiędzy tymi typami, które są właściwą domeną dla
> analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w
> stereotypach albo innych dekoracjach w relacjach pomiędzy tymi
> właściwymi typami, zakładając, że IF jest już częścią języka
> programowania (dotyczy to wszystkich konstrukcji typu MPL).
> Odpowiedni generator potrafiłby taką iluzję stworzyć.
Czyli dochodzi Ci potrzeba użycia dodatkowego utilka pokazującego na
zależność
pomiędzy typami.
> > Tak więc jeśli możesz wskazać na
> > jakieś opracowania
> > w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> > "boost::" to chętnie
> > poczytam.
>
> Nie znam żadnych takich opracowań. :-)
Szkoda :-).
Pozdrawiam, Seweryn Habdank-Wojewódzki.
Seweryn Habdank-Wojewódzki
Jarosław Żeliński napisał(a):
> UML to nie jest język programowania,
Oczywiście.
> jednego celem jest wsparcie procesu
> analizy, modelowanie i opracowanie koncepcji systemu oraz zebranie np.
> wymagań na system.
Tak. Tylko, że jest wiele utilków, które zamieniają UML na kod. A
dwa co zrobić, aby pokazać coś czego UML nie potrafi.
> Jeżeli jakieś narzędzie pozwala wyeksportować model w tai sposób, że możliwe
> jest wygenerowanie nawet części kodu to mamy dodatkowo zmniejszenie
> pracochłonności.
I tu włąsnie pojawia się drugi wspomniany przezemnie problem. Bo
nawet jeśli trzeba UML przepisać na kod. To i tak na diagrame UML
trzeba zaznaczyć ołówkiem to czego standard nie przewiduje.
> Literatura podaje: dobre i udane projekty IT:
> - 50% czasu na analizę i modelowanie
> - 30% kodowanie
> - 20% testy i oddanie do użytku.
To może być prawda nie potrafię ocenić, ale co jest ogólniejsze
niż UML czy BON tak, żeby
można było standardowo umijscowić nie tylko relacje pomiędzy
metodami, zawieraniem się obiektów czy innymi typowymi sprawami, a
także relacje pomiędzy
typami parametryzującymi.
Pozdrawiam, Seweryn Habdank-Wojewódzki
DarekM
> >
> Literatura podaje: dobre i udane projekty IT:
> - 50% czasu na analizę i modelowanie
> - 30% kodowanie
> - 20% testy i oddanie do użytku.
>
>
>
Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
analiza : 5 osób pracuje przez rok -
testy : 30 osób pracuje przez miesiąc
i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%
Chyba że w "literaturze" podaje się czas adaptacji programu, to można
się zgodzić. Ale jeżeli to są adaptacje (parametryzacja, modyfikacje czy
jakkolwiek to nazwiemy) to należy to wyraźnie zaznaczyć. Czy innym jest
tworzenie systemu od podstaw a czym innym przystosować istniejący do
nowych potrzeb.
Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste.
Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc
analiza trwa 4 lata, konsumowane jest większość budżetu a potem
informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się
nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system
oczywiście przekraczając wszystkie limity oprócz jakości. Żeby nie
było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby
ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to
przykład jak przytoczone wskaźniki mogą powstawać.
Darek
Jacek Pietraszek
> Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
> analiza : 5 osób pracuje przez rok -
> testy : 30 osób pracuje przez miesiąc
> i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
> SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%
Kula w plot. Te 5 osobolat to tylko customizacja, wiec nie
porownuj tego do czasochlonnosci napisania ERP-a, tylko
do czasochlonnosci napisania poprawek, dostosowan i raportow.
A to w 1 osoboroku sie zmiesci. Zreszta nie przesadzaj z tym
1K osobolat dla budowy ERP-a. To nie program Apollo :)
> Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste.
> Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc
> analiza trwa 4 lata, konsumowane jest większość budżetu a potem
> informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się
> nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system
> oczywiście przekraczając wszystkie limity oprócz jakości. Żeby nie
> było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby
> ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to
> przykład jak przytoczone wskaźniki mogą powstawać.
Przyklad instytucji budzetowej nie jest wlasciwy, bo to
patologia zarzadzania. Sam w takowej siedze jedna noga
i szlag mnie trafia, jak widze marnotrawsto nie tyle
pieniedzy wprost, ale mojego i kolegow czasu.
Glowne problemy trapiace kierownictwo:
a) jak tu zrobic, zeby nic nie zrobic,
b) jak juz trzeba cos zrobic, to jak to zrobic, aby nic nie zmienic,
c) jak tu zrobic, aby samemu zarobic (nagrody itp.), ale nie dac
zarobic nikomu nizej.
Niesmak bierze, tym bardziej, ze osoby utytulowane, wiec
w naiwnosci moznaby przypuszczac, ze na poziomie. Niestety,
stara kadra profesorska, ktora miala przynajmniej kindersztube
wymiera. A ja mimo kilkunastu lat pracy nie moge do tego
balaganu przywyknac.
Za duzo widac kontaktu ze zdrowym, drapieznym biznesem :)
--
Pozdrawiam,
Jacek
DarekM
> DarekM <dar...@emadar.com> napisal:
>> Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
>> analiza : 5 osób pracuje przez rok -
>> testy : 30 osób pracuje przez miesiąc
>> i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
>> SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%
>
> Kula w plot. Te 5 osobolat to tylko customizacja, wiec nie
> porownuj tego do czasochlonnosci napisania ERP-a, tylko
> do czasochlonnosci napisania poprawek, dostosowan i raportow.
Popatrz na cel wypowiedzi. Właśnie to starałem się wykazać natomiast
podane proporcje czasochłonności projektu IT tym nie wspominają (chyba
że cytujący wyciął je z kontekstu). Ja mówię o wprowadzaniu w błąd
takimi statystykami.
> A to w 1 osoboroku sie zmiesci. Zreszta nie przesadzaj z tym
> 1K osobolat dla budowy ERP-a. To nie program Apollo :)
Podałem konkretne oszacowanie dla SAP (bo słynny), oni tyle mają
koderów. Natomiast dolne ograniczenie też mogę oszacować, nawet z
autopsji. Tyle że nie o to tutaj chodzi
>
>> Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste.
>> Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc
>> analiza trwa 4 lata, konsumowane jest większość budżetu a potem
>> informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się
>> nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system
>> oczywiście przekraczając wszystkie limity oprócz jakości. Żeby nie
>> było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby
>> ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to
>> przykład jak przytoczone wskaźniki mogą powstawać.
>
> Przyklad instytucji budzetowej nie jest wlasciwy, bo to
> patologia zarzadzania. Sam w takowej siedze jedna noga
> i szlag mnie trafia, jak widze marnotrawsto nie tyle
> pieniedzy wprost, ale mojego i kolegow czasu.
>
> Glowne problemy trapiace kierownictwo:
> a) jak tu zrobic, zeby nic nie zrobic,
> b) jak juz trzeba cos zrobic, to jak to zrobic, aby nic nie zmienic,
> c) jak tu zrobic, aby samemu zarobic (nagrody itp.), ale nie dac
> zarobic nikomu nizej.
>
To dotyczy również instytucji naukowych oraz bardzo dużych firm.
Oczywiście w mniejszym stopniu ale jednak.
> Niesmak bierze, tym bardziej, ze osoby utytulowane, wiec
> w naiwnosci moznaby przypuszczac, ze na poziomie. Niestety,
> stara kadra profesorska, ktora miala przynajmniej kindersztube
> wymiera. A ja mimo kilkunastu lat pracy nie moge do tego
> balaganu przywyknac.
Też mnie to rozczarowało
>
> Za duzo widac kontaktu ze zdrowym, drapieznym biznesem :)
Wiadomo jak jest, delikatnie mówiąc nieidealnie. Mój głos ma na celu
zwrócenie uwagi, albo raczej poszukiwanie drogi w zagadnieniu: "jak
skutecznie wdrażać systemy IT" i to w takich warunkach i przy takich
zasobach jakie są.
Jarosław Żeliński
wiadomości news:1161242352....@e3g2000cwe.googlegroups.com...
Tak. Tylko, że jest wiele utilków, które zamieniają UML na kod. A
dwa co zrobić, aby pokazać coś czego UML nie potrafi.
> Tu chyba problem w tym, by nie traktowac UML (czy innych takich) jako
> narzędzia programowania a tylo jako analityczne. Jeżeli ktos opisał np.
> Use CAsem zawarł tak jakies Extendy ew, cos skomentował to programista ne
> musi łazić po firmie klienta tyko siada i koduje, jego kompetencją jest
> zreaizowac zamysł z projektu i ewentualnie podyskutowac z analitykiem,
> jeżeli cos jest niewykonalne..
...
I tu włąsnie pojawia się drugi wspomniany przezemnie problem. Bo
nawet jeśli trzeba UML przepisać na kod. To i tak na diagrame UML
trzeba zaznaczyć ołówkiem to czego standard nie przewiduje.
> tu chyba pojawia się odwieczny problem: na ile korzytać ze standardów a na
> ile z wąłsnych pomysłow.... potem przychodzi temat pracochłonności
> konserwacji oprogramowania...
--
Jarek
http://jarek.zelinski.biz.pl/
Jarosław Żeliński
jest jednak istotna różnica pomiędzy pisaniem systemu na zamówienie a
wdrażaniem gotowej kobyły z setkami parametrów. Po drugie pracochłonność i
koszt nie tylko konsultantów z SAP oraz ich produkty (opracowania) nie są
dla mnie żadnym wyznacznikiem, dla mnie miernikiem jakości pracy analityka
jest różnica pomiędzy modelem jaki wykonał on przed wdrożeniem a tym co jest
po jego zakończeniu.
Tu się okazuje, ze setki stron jakichś procesów narysowanych na bazie ankiet
z pracownikami (pomijam, że w Visio) bez żadnego odniesienia do rynkowych
realiów analizowanej firmy prowadzi do pracy na półkę, której nawet zarząd
firmy nie potrafi przebrnąć.
Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia organizacji
klienta, opisania tego jak pracuje (model procesowy) a potem do
zaprojektowania narzędzia (czyli aplikacji) która tę organizację będzie
wspierała (np. model w UML). Po analityku może np. wejść sztab systemowców i
programistów, którzy szybko gotowy obiektowy projekt zakodują, i pierwsza
wersja powinna być. Potem oczywiście ewentualne prace nad ulepszeniem.
--
--
Jarek
http://jarek.zelinski.biz.pl/
Użytkownik "DarekM" <dar...@emadar.com> napisał w wiadomości
news:eh8boo$s5t$1...@node5.news.atman.pl...
DarekM
> Tak się tworzy spiskowe teorie dziejów....
chciałem pokazać jak można ją interpretować. Wiem że są to skrajności,
ale też wiem że nie wszystkie
>
> jest jednak istotna różnica pomiędzy pisaniem systemu na zamówienie a
> wdrażaniem gotowej kobyły z setkami parametrów. Po drugie pracochłonność i
> koszt nie tylko konsultantów z SAP oraz ich produkty (opracowania) nie są
> dla mnie żadnym wyznacznikiem, dla mnie miernikiem jakości pracy analityka
> jest różnica pomiędzy modelem jaki wykonał on przed wdrożeniem a tym co jest
> po jego zakończeniu.
bez analityka, a przydałby się czasami aby wytłumaczyć że jest ślepa
uliczka.
>
> Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia organizacji
> klienta, opisania tego jak pracuje (model procesowy) a potem do
> zaprojektowania narzędzia (czyli aplikacji) która tę organizację będzie
> wspierała (np. model w UML).
W zasadzie masz rację , brakuje mi tylko stwierdzenia z jakim produktem
startujemy. Czy to będzie rozwiązanie dedykowane (pisane od nowa na
zamówienie) , parametryzowane (tak jak duże systemy ERP) czy też w miarę
uniwersalny produkt który należy odpowiednio skonfigurować i nauczyć
obsługiwać.
Po analityku może np. wejść sztab systemowców i
> programistów, którzy szybko gotowy obiektowy projekt zakodują, i pierwsza
> wersja powinna być. Potem oczywiście ewentualne prace nad ulepszeniem.
>
I z tym się nie zgodzę. Takie rzeczy to tylko z gotowymi produktami.
Program narzuca pewien szkielet, którego musimy się trzymać. Analityk
musi podjąć 3-5 kluczowych decyzji związanych z dostosowanie programu do
klienta albo odwrotnie. Żeby nie było, uważam to za naprawdę trudne zadanie.
Jeżeli mówimy o systemach dedykowanych to pierwsza działająca wersja
będzie po ... latach. Jakaś część analizy się zdezaktualizuje, jakąś
trzeba będzie uzupełnić (czasami robią to programiści własnymi siłami).
Natomiast oprócz zakodowania modelu należy jeszcze zrobić ten fragment
programu, który odpowiedzialny jest za funkcjonowanie programu w
rzeczywistości tak aby dane były wprowadzane sprawnie, pozyskiwane
informacje wiarygodnej system działał stabilnie przy takich zasobach i
takiej rzeczywistości jaka jest (a nie taka jak analityk założył, tzn.
jeżeli analityk nie założył błędów użytkownika to ich nie będzie).
Przykro mi ale wg mnie analityk bardzo przypomina mi architekta przy
budowie domu. Zazwyczaj projekt domu obejmuje elementy zewnętrzne: bryłę
domu kształt dachu, usadowienie na działce i tym podobne. Tak aby dom
był śliczny. Natomiast funkcjonalność i ergonomia to dla wielu
architektów nieznane pojęcia. To że łazienka jest na jednym końcu domu a
kuchnia drugim to nic, przecież można zrobić 2,3 4 piony kanalizacyjne.
To że do kuchni przechodzi się przez salon to również rzecz spotykana.
Tyle że przynajmniej to jest. Natomiast brak: instalacji elektrycznej,
alarmowej, telekomunikacyjnej, wentylacji, ogrzewania, dekoracje na
ścianach, stolarka otworowa i wielu innych (każdy kto coś
budował/remontował na podstawie projektu wie ile musiał podjąć decyzji).
Oczywiście istnieją dobrzy architekci ale żaden z nich nie schodzi do
poziomu poszczególnych elementów kolejnych instalacji. To wykonują
kolejne ekipy czasami tworząc projekt, czasami nie.
Proszę mnie uświadomić, czy analityk jest w stanie zawrzeć w analizie
większość istotnych szczegółów koniecznych do zbudowania aplikacji.
Kolejne porównanie: czy dobra analiza stanowi coś w stylu partytury, na
podstawie której można rozpisać nuty dla każdego instrumentu nieomal
automatycznie. Wg mnie nie, ale może się nie znam.
Darek
Jarosław Żeliński
> Jarosław Żeliński napisał(a):
>> Tak się tworzy spiskowe teorie dziejów....
> To ty zacząłeś rzucając jakąś statystykę bez krzty komentarza. Ja tylko
> chciałem pokazać jak można ją interpretować. Wiem że są to skrajności, ale
> też wiem że nie wszystkie
Masz rację, statyska ta dotyczyła projektów "pisania od zera".
[...]
> Można jeszcze wdrażać Excel/Visio . W większości przypadków robi się to
> bez analityka, a przydałby się czasami aby wytłumaczyć że jest ślepa
> uliczka.
Ano święte słowa. To właśnie projekty powstaajce na bazie bezsensownych
ankiet i dziesiątek niekontrolowalych schematów w Visio.
>> Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia
>> organizacji klienta, opisania tego jak pracuje (model procesowy) a potem
>> do zaprojektowania narzędzia (czyli aplikacji) która tę organizację
>> będzie wspierała (np. model w UML).
> W zasadzie masz rację , brakuje mi tylko stwierdzenia z jakim produktem
> startujemy. Czy to będzie rozwiązanie dedykowane (pisane od nowa na
> zamówienie) , parametryzowane (tak jak duże systemy ERP) czy też w miarę
> uniwersalny produkt który należy odpowiednio skonfigurować i nauczyć
> obsługiwać.
Moim zdaniem jeżeli planujemy wdrożenie gotowego systemu to robienie mapy
procesów bardziej szczegołowej niż kluczowe zadania w firmie z
uwzględnieniem podstawowych (nieusuwalych z firmy) dokumentów jest
nieporozumiem.
Jeżeli planujemy system od zera to dobrze jest opisać procesy do poziomu
wszytkich czyności jakie są wykonywane w tym obszarze firmy który b ędzie
beneficjentem nowego systemu (bez zbytnich szczegółów ich realizacji). Wtedy
z takiej mapy procesów (po ewentualnej optymalizacji) bardzo łatwo wyłuskać
wszystrkie przypadki użycia systemu.
> Po analityku może np. wejść sztab systemowców i
>> programistów, którzy szybko gotowy obiektowy projekt zakodują, i pierwsza
>> wersja powinna być. Potem oczywiście ewentualne prace nad ulepszeniem.
>>
> I z tym się nie zgodzę. Takie rzeczy to tylko z gotowymi produktami.
> Program narzuca pewien szkielet, którego musimy się trzymać. Analityk musi
> podjąć 3-5 kluczowych decyzji związanych z dostosowanie programu do
> klienta albo odwrotnie. Żeby nie było, uważam to za naprawdę trudne
> zadanie.
>
Szkielet narzuca gotowy system, pisany na zamowienie żadnego. Czy źle
zrozumiałem?
>
> Jeżeli mówimy o systemach dedykowanych to pierwsza działająca wersja
> będzie po ... latach. Jakaś część analizy się zdezaktualizuje, jakąś
> trzeba będzie uzupełnić (czasami robią to programiści własnymi siłami).
> Natomiast oprócz zakodowania modelu należy jeszcze zrobić ten fragment
> programu, który odpowiedzialny jest za funkcjonowanie programu w
> rzeczywistości tak aby dane były wprowadzane sprawnie, pozyskiwane
> informacje wiarygodnej system działał stabilnie przy takich zasobach i
> takiej rzeczywistości jaka jest (a nie taka jak analityk założył, tzn.
> jeżeli analityk nie założył błędów użytkownika to ich nie będzie).
>
>
No to dyskusja raczej inna już dyskusja o sposobie tworzenia oprogramowanie.
Nie zabiorę w niej głosu bo zawodowo nie koduję. Ale to tworzenie "przez
lata" do mnie nie przemawia. No chyba, że siadają programiści i piszą "na
czuja" bez modelu systemu, którego "oni nie potrzebują". Znam wiele takich
projektów programistycznych, faktycznie mają szanse być "a lata".
> Przykro mi ale wg mnie analityk bardzo przypomina mi architekta przy
> budowie domu. Zazwyczaj projekt domu obejmuje elementy zewnętrzne: bryłę
[...]
Owszem, ale opisałeś tu architekta, który stworzył projekt domu bez wymagań
przyszłego użytkownika tylko na bazie swojego widzimisię. Np. kuchnia z
przejściem przez salon mnie osobiście pasuje, jest ona u mnie elementem
użytkowego parteru. Więc kwestia gustu a to kolejny przyczynek do wykonania
bardzo dokładnej analizy wymagań.
>
> Proszę mnie uświadomić, czy analityk jest w stanie zawrzeć w analizie
> większość istotnych szczegółów koniecznych do zbudowania aplikacji.
Czyli jakich? Funkcjonalnych czy kodowych? Posługując się porównaniem do
architekta: architekt powinien umieć zaprojektwac dom wygodny i akceptowalny
dla użytkownika, zaś to czy rurki będą z PCV czy z miedzi to inna decyzja i
to dla inżyniera a nie architeta (może on cos sugerowąć) ale łazienka i woda
w kranie zimna i ciepła musi być.
> Kolejne porównanie: czy dobra analiza stanowi coś w stylu partytury, na
> podstawie której można rozpisać nuty dla każdego instrumentu nieomal
> automatycznie. Wg mnie nie, ale może się nie znam.
>
Partytura to właśnie rozpisane nuty na instrumenty. Rzecz w tym, że to
dyrygent i wykonawcy intepretują utwór napisany przez kompozytora i nie
widze tu żadnej sprzecznosci :). Należy tylko pamiętać, że nawet najlepszy
utwór można spaprać ale najlepszy dyrygent i muzycy nie naprawią nudnego i
niedajacego sie słuchac utworu.
DarekM
> Użytkownik "DarekM" <dar...@emadar.com> napisał w wiadomości
> news:ehiped$10v$1...@node5.news.atman.pl...
>> Jarosław Żeliński napisał(a):
>>> Tak się tworzy spiskowe teorie dziejów....
>> To ty zacząłeś rzucając jakąś statystykę bez krzty komentarza. Ja tylko
>> chciałem pokazać jak można ją interpretować. Wiem że są to skrajności, ale
>> też wiem że nie wszystkie
>
> Masz rację, statyska ta dotyczyła projektów "pisania od zera".
>
> [...]
> Jeżeli planujemy system od zera to dobrze jest opisać procesy do poziomu
> wszytkich czyności jakie są wykonywane w tym obszarze firmy który b ędzie
> beneficjentem nowego systemu (bez zbytnich szczegółów ich realizacji). Wtedy
> z takiej mapy procesów (po ewentualnej optymalizacji) bardzo łatwo wyłuskać
> wszystrkie przypadki użycia systemu.
>
>
>> Po analityku może np. wejść sztab systemowców i
>>> programistów, którzy szybko gotowy obiektowy projekt zakodują, i pierwsza
>>> wersja powinna być. Potem oczywiście ewentualne prace nad ulepszeniem.
>>>
>> I z tym się nie zgodzę. Takie rzeczy to tylko z gotowymi produktami.
>> Program narzuca pewien szkielet, którego musimy się trzymać. Analityk musi
>> podjąć 3-5 kluczowych decyzji związanych z dostosowanie programu do
>> klienta albo odwrotnie. Żeby nie było, uważam to za naprawdę trudne
>> zadanie.
>>
> Szkielet narzuca gotowy system, pisany na zamowienie żadnego. Czy źle
> zrozumiałem?
No teraz już wiem w czym sie nie zgadzamy. Wg mnie stan jest taki:
analityk nie ma pojęcia co ma do zrobienia programista, a ten co
analityk. Konsekwencją tego jest umniejszanie roli tego drugiego.
Dwa cytaty z głowy:
"po co mi analityk (analiza) jeżeli klient za to nie chce zapłacić"
"Po analizie programista szybko zakoduje projekt"
To rodzi duże nieporozumienia, a potem urażona duma itd. (nie mówię że w
tej dyskusji się ktokolwiek obraził)
>
>
>> Jeżeli mówimy o systemach dedykowanych to pierwsza działająca wersja
>> będzie po ... latach. Jakaś część analizy się zdezaktualizuje, jakąś
>> trzeba będzie uzupełnić (czasami robią to programiści własnymi siłami).
>> Natomiast oprócz zakodowania modelu należy jeszcze zrobić ten fragment
>> programu, który odpowiedzialny jest za funkcjonowanie programu w
>> rzeczywistości tak aby dane były wprowadzane sprawnie, pozyskiwane
>> informacje wiarygodnej system działał stabilnie przy takich zasobach i
>> takiej rzeczywistości jaka jest (a nie taka jak analityk założył, tzn.
>> jeżeli analityk nie założył błędów użytkownika to ich nie będzie).
>>
>>
>
> No to dyskusja raczej inna już dyskusja o sposobie tworzenia oprogramowanie.
> Nie zabiorę w niej głosu bo zawodowo nie koduję. Ale to tworzenie "przez
> lata" do mnie nie przemawia. No chyba, że siadają programiści i piszą "na
> czuja" bez modelu systemu, którego "oni nie potrzebują". Znam wiele takich
> projektów programistycznych, faktycznie mają szanse być "a lata".
To powiedz mi dlaczego projekty typu Windows, Linux, Sap R3, Płatnik,
Poltax powstawały lata. Bynajmniej nie dlatego że nie miały fazy analizy
ani że oszczędzali na analitykach.
>
Widziałem projekt konsolidacji bilansu dla korporacji, niby poważna
sprawa. Projekt się udał i działa ale z punktu widzenia informatycznego
to tylko przekształcenie 2000 liczb w 200. Działało bo
człowiek+Excel+Akces są w stanie to ogarnąć. Gdyby natomiast chodziło o
20000 liczb, lub co gorsza 2000000 to błędne były fundamentalne
założenia. Proszę popatrz jak dławią się aplikacje dla ZUS, Urzędu
skarbowego. I kto jest winien programista który nie potrafi spełnić
nierealnych życzeń analityka, czy analityk który nie uwzględnił
możliwości technologicznych. A może w celu stworzenia dużego systemu
informatycznego należy wykonać dogłębną analizę, która stanowi szkielet
na którym programiści "dziergają" oczko po oczku każdy element składowy.
>
>
>> Przykro mi ale wg mnie analityk bardzo przypomina mi architekta przy
>> budowie domu. Zazwyczaj projekt domu obejmuje elementy zewnętrzne: bryłę
> [...]
> Owszem, ale opisałeś tu architekta, który stworzył projekt domu bez wymagań
> przyszłego użytkownika tylko na bazie swojego widzimisię. Np. kuchnia z
> przejściem przez salon mnie osobiście pasuje, jest ona u mnie elementem
> użytkowego parteru. Więc kwestia gustu a to kolejny przyczynek do wykonania
> bardzo dokładnej analizy wymagań.
>
>> Proszę mnie uświadomić, czy analityk jest w stanie zawrzeć w analizie
>> większość istotnych szczegółów koniecznych do zbudowania aplikacji.
>
> Czyli jakich? Funkcjonalnych czy kodowych? Posługując się porównaniem do
> architekta: architekt powinien umieć zaprojektwac dom wygodny i akceptowalny
> dla użytkownika, zaś to czy rurki będą z PCV czy z miedzi to inna decyzja i
> to dla inżyniera a nie architeta (może on cos sugerowąć) ale łazienka i woda
> w kranie zimna i ciepła musi być.
A kto to ma zrobić jak nie architekt. Przecież inżynier nie będzie
montować instalacji. Pamiętaj że to użyte na potrzeby analogii. Jeżeli
instalację dobiera inżynier to tworzy on kolejny projekt, kolejną
analizę. Przecież programista tylko koduje.
Przykład z życia: zamówiłem projekt schodów tzn. chciałem wygodnie móc
wchodzić na piętro, schody miały być w korytarzu w istniejącym budynku.
Architekt zrobił projekt a jakże, kilkanaście stron rysunków i obliczeń.
Tyle że zupełnie nieprzydatny. Jedyny wymiar który sie zgadzał to była
liczba schodów (którą to i tak musiałem wybrać). Reszta łącznie z
szerokością, wysokością poręczy, punktem zaczepienia uzgadniałem na
bieżąco z wykonawcą. Belka stropowa była grubsza niż krokwie w kościele itd.
Wiem że to był patałach a nie architekt, ale nie mów że ten jest jedynie
do policzenia ilości schodów.
Trochę inna analogia to projektant samochodów. Ten też ma się pytać
przyszłego użytkownika o twardość amortyzatorów, czy może inżyniera w
montowni.
>
>
>> Kolejne porównanie: czy dobra analiza stanowi coś w stylu partytury, na
>> podstawie której można rozpisać nuty dla każdego instrumentu nieomal
>> automatycznie. Wg mnie nie, ale może się nie znam.
>>
> Partytura to właśnie rozpisane nuty na instrumenty. Rzecz w tym, że to
> dyrygent i wykonawcy intepretują utwór napisany przez kompozytora i nie
> widze tu żadnej sprzecznosci :). Należy tylko pamiętać, że nawet najlepszy
> utwór można spaprać ale najlepszy dyrygent i muzycy nie naprawią nudnego i
> niedajacego sie słuchac utworu.
Bardzo dobrze interpretacja jest bardzo blisko implementacji. Pytanie
tylko czy nie mamy do czynienia z improwizacją na dużą skalę.
Mam wrażenie że obecnie to występują dwa przypadki. Pierwszy analityk po
dokonaniu analizy koduje/parametryzuje system. Drugi programista aby
system zrealizować wykonuje analizę na własne potrzeby.
Ustalmy podział pracy pomiędzy analityka i programistę a wtedy można
będzie oszacować wkład pracy.
Darek
Jarosław Żeliński
komunikacja :)
Ogólnie moim zdaniem jest tak prawie jak napisałeś:
jakieś dane -> czynność (praca np. analityka) -> produkt (np. model UML z
efektami) -> programista (czyta model i wie co trza zakodować) -> program
do tego kilka iteracji jest luzik, podstawa: unormowane zakres
odpowiedzialności i narzędzie komunikacji .. tych etapów pośrednich może być
więcej ..ale sens jest taki
--
--
Jarek
http://jarek.zelinski.biz.pl/
Użytkownik "DarekM" <dar...@emadar.com> napisał w wiadomości
news:ehlbc7$e3j$1...@node5.news.atman.pl...
Piotr Dembiński
[...]
> Przykład z życia: zamówiłem projekt schodów tzn. chciałem wygodnie
> móc wchodzić na piętro, schody miały być w korytarzu w istniejącym
> budynku. Architekt zrobił projekt a jakże, kilkanaście stron
> rysunków i obliczeń. Tyle że zupełnie nieprzydatny. Jedyny wymiar
> który sie zgadzał to była liczba schodów (którą to i tak musiałem
> wybrać). Reszta łącznie z szerokością, wysokością poręczy, punktem
> zaczepienia uzgadniałem na bieżąco z wykonawcą.
A kto znał normy budowlane na schody: ty, architekt czy wykonawca?
Marcin
W Rational Real Time (w wersja 2003 - mozna sciagnac triala), sa przyklady
tworzenia aplikacji od podstaw do dzialajacego kodu. Oczywiscie calosc ma za
zadanie pokazac jak korzytsac ze srodowiska ale zapewne jestes inteligentnym
czlowiekiem i szybko odzielisz UML'a od IDE. Do kompilacji modelu potrzebujesz
jeszcze jakiegos kompilatora zewnetrznego ale zdaje sie, ze widzialem na liscie
MinGW (gcc na Win). Calosc dotyczy real time wiec w takim podejsciu jest duzo
diagramow stanow, klas aktywnych etc. co niekoniecznie moze wspolgrac z
aplikacjami pisanym na PC w stylu Office'a (GUI driven).
Jak juz zainstalujesz to radze szukac w sekcji tutoriali. Najprostszy jest
'Hello World' a potem jakies przyklady z gra w karty, coffe machine chyba
przyklad z winda etc.
Pozdrawiam
Marcin
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl