[linux] Re: EIS - aky programatorsky nastroj - sumarizacia [long]

[Matej Pivoluska]

Dňa Pi 11. Apríl 2003 02:24 M.F. PSIkappa napísal(a):
> Vacsinou pri serioznych enterprise rieseniach typu ekonomicky informacny
> system (komplex urcitych podsystemov) sa zacina s vyberom metodologie a
> metod a potom z toho sa to odvija dalej.
> A dalej sa postupuje analyzou, navrhom, implementaciou, testovanim a tak
> dalej... v niektorych metodologiach aj podrobnejsie...

Dakujem Ti, ze si to zvrtol spravnym smerom, mne to akosi dnes rano okolo 
polnoci nepreplo, ze keciame o jednotlivych implementacnych detailoch bez 
nejakeho nadhladu na cely system. Ale, na druhej strane, ta exkurzia snad 
nikomu neuskodila. ;-)

> Cize vyber DB, programovacieho jazyka a takychto veci je az v neskorsich
> fazach.
>
> Urcite sa zamysli nad pouzitim trojvrstvej architektury a dobre je uz pri
> navrhu mysliet na modularitu a parametrizovatelnost. Vsetko rozdelit na
> podsystemy, moduly, objekty, a ak sa to da tak im zabezpecit urcitu
> nezavislost.
>
> A teraz k veci:
> 1. Je jedno absolutne v com to napises, ak raz bude v narvhu, ze dany
> modul musi mat taketo a taketo vlastnosti a musi pouzivat taketo rozhrania
> a volania, tak si to uz implementator-programator moze napisat trebars aj
> v eiffely.

Uplne suhlasim, ak bude dobra urobeny navth jednotilvych casti systemu a budu 
dobre definovane rozhrania, je to (takmer) uplne jedno. Na druhej strane je 
vsak len vyhodne, ak nebude kazdy modul napisany v nejakom inom programovacom 
jazyku.
BTW: Aj smalltalk je celkom prijemny jazyk. ;-)

> 2. Prisne musia byt oddelene data, od logiky a od prezentacnej vrstvy.
> Tusim sa tomu nadava MVC model.
> 3. Snaz sa byt databazovo nezavisly, v podstate ti staci hocijaka DB s
> plnou podporou ANSI ISO-SQL92.

Hmm, teoreticky to znie dobre, ale za aku cenu? Urcite je to dobra idea, ale 
uplne ju asi zrealizovat nepojde. Urcite sa vyskytnu pripady, kedy bude 
vyhodnejsie pouzit nejake nestandardne rozsirenia tej ktorej DB., resp. 
nemusia byt niektore veci zo standardu implementovane v tej ktorej db. Ale je 
dobre mysliet na to, aby sa dal vymenit SQL server s minimalnymi (resp. 
ziadnymi) zasahmi do kodu, najlepsie len doimplementovanim konektorov pre 
jednotlive servery. (Dedicnostou.) To je jedna z veci, o ktoru sa ma postarat 
dobry navrh.

> V podstate mozes uplatnit asi len 2 metodologie, sialenosti typu MERISE
> neratam:
> a) SSADM - strukturovany pristup
> b) OMT2 - objektovy pristup

Prihovaram sa za objektovy pristup, predsa len je napr. lahsie pochopitelny aj 
pre cloveka, ktory posobi v inom obore a podla mna sa v nom neda tak rychlo 
stratit ako pri strukturovanom pristupe.

> Skus si pre zaciatok dost presne definovat, co vsetko od toho ocakavas a
> pre aku velkost firmy chces to robit.

Urcite by bolo vhodne spravit app skalovatelnu. Ale znovu, v navrhu treba na 
to mysliet, no implementovat sa hned vsetko neoplati. Treba zacat skromne, 
potom sa mozu pridavat nove moduly a optimalizovat stare.



-- 
Matej Pivoluska (mP)
Charles University in Prague
Faculty of Mathematics and Physics

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d+ s++: a--->-- C++$ UL+++$ P+++@ L+++$ E--- W++ N+ o? K? w-- O- 
M@ V- PS PE+ Y+ PGP++ t@ 5 X-- R !tv b++++ DI? D  G++ e>++++ h r++ y? 
------END GEEK CODE BLOCK------