Budovanie informačných systémov I. - Úvod

Libor Bešenyi  /  13. 07. 2006, 00:00

V prvej časti tohto nového seriálu si predstavíme najdôležitejšie informácie o jeho smerovaní, čo od neho môžete očakávať a pre koho je vlastne určený. Zároveň sa pozrieme aj na vývojový proces budovania podnikových systémov.

O seriáli...

V dnešnej dobe na Slovensku zaznamenávame obrovský nárast dopytu po informačných systémoch hlavne pre malé podniky. Tie boli v minulosti výsadou korporácií a neskôr sa dostali aj do sféry firiem strednej veľkosti. Takéto robustné aplikácie presahujúce neraz cenu jedného milióna korún sú ale stále nedosiahnuteľné pre malých podnikateľov. Tí sa však vynašli: nechávajú si ich budovať medzi študentmi stredných a vysokých škôl. Ako sa vytvárajú, si ukážeme v tomto seriáli. Nebude však primárne zasvätený programovaniu! Rozoberiem pár metód, či techník, ale mojim cieľom je čitateľovi vštiepiť isté analytické základy.

Rozdelíme si seriál na dve časti. Prvá sa bude venovať základnej terminológii s vybudovaním jednoduchého systému. Na programovanie si zvolíme Delphi a ako databázový systém bude postačovať MySQL okolo verzie 3. V tejto časti sa nebudú popisovať nejaké progresívne metódy a technológie. Ukážeme si základnú syntax SQL, prepojenie Delphi s MySQL pomocou ODBC a pracovanie so starým, dobrým a predsa zaznávaným BDE rozhraním. Postupne si naprogramujeme prostý demonštračný systém s aktualizáciami databázy, autonómneho zotavovania z problémov databázových objektov (registrovanie aliasov apod.), tvorbu záloh a ich obnovu + nejaký ten systém privilégií užívateľov. Celú funkčnosť vložíme do Delphi.

Druhá časť seriálu odhalí krásu a jednoduchosť technológii a poukáže na množstvo chýb, ktorých sme sa dopustili ako začiatočníci v predchádzajúcej časti (takto totiž postupuje mnoho samoukov programátorov). Začneme modelovať databázu v nejakom designeri, logiku vložíme do databázového systému FireBird (triggre a storované procedúry) - teraz využijeme dbExpress. Ukážeme si programovanie MDI aplikácii s modulárnym jadrom (DLL knižnice), plne konfigurovateľné rozhranie pre prácu s modulmi a dynamické generovanie objektov. No a v závere sa pozrieme na tvorbu webových služieb v Delphi. Nielen C# a ASPX s .Net dokážu totiž divy! Delphi ponúka taktiež širokú škálu technológii pre prácu s webovými výstupmi. Informácii na internete je úboho málo a tak túto škárku aspoň trochu vyplním pár článkami o budovaní servera pre tenkých klientov (prehliadač) pomocou webového IIS-ka od Microsoftu a ISAPI prístupom (WebSnap) s designovaním pomocou IntraWebu.

Aké skúsenosti bude potrebovať čitateľ? Základne znalosti ovládania a fungovania Delphi, základne vedomosti z programovania a ovládania Pascalovskej syntaxe.

Čo sa týka otázok a pripomienok, prosím píšte na mail, pretože som pomerne časovo vyťažený, neviem ako budem stíhať reagovať na prípadnú diskusiu.

Poznámka: K napísaniu seriálu ma dohnalo kriticky málo informácii, ktoré sa na internete nachádzajú k rôznym problematikám, s ktorými sa budeme zapodievať. Tak som ich zastrešil do tejto pomerne komplexnej tematiky. Apelovať chcem však na tých, ktorí nebudú súhlasiť s niektorými metódami: Seriál nie je venovaný profesionálom a niektoré techniky (hlavne z prvej časti) naschvál vyberám „chybné". Nechcem týmto čitateľa zavádzať, ale postupujem podľa vlastných zdrojových kódov, keď som začínal a tých chýb sa dopúšťal ako každý začiatočník. Odbornejšími informáciami zahrniem čitateľa v druhej časti seriálu.


Ako začať?

Všetci pokladajú programátorov za nejakú vyššiu kastu. To je ale chyba... Programátor nie je nič iné, ako obyčajný robotník vo fabrike, ktorý ale zarába mnohonásobne viac. Robota obyčajného programátora po určitej dobe naberá na rutine a počiatočné nadšenie odpadáva...

Vývoj aplikácie ale neznamená len programovanie, čo si väčšina ľudí myslí. Ako povedal môj učiteľ informatiky: „Ak je vytvorená špecifikácia, odprogramuje to už hocijaký stredoškolák." Trocha sa ma to vtedy dotklo, ale bola to pravda. Žiaden kumšt sa v kódení neskrýva. Dôležitá je špecifikácia!

Taktiež pri tvorbe kancelárskych systémov nie je dôležitý nápad, ale realizácia. S jedným projektom som osobne mal problém, keď náčrtky výstupov zákazník považoval za gro celého systému. Nevedel som v tej dobe, či je to pravda, no teraz s určitosťou môžem povedať, že to je len nejakých desať percent z problému! Dokonca v nejakej knihe som čítal niečo v tom zmysle, že nemyslime si o zákazníkovi, ktorý so sebou prinesie náčrtky, že je debilný... Tieto informácie sú zadaním, nie však riešením a tobôž nie výsledkom a postupom riešenia. Preto dopredu treba určiť pravidlá hry, ak máme náš program predávať.

A chcem aj upozorniť na legálnosť. Na nelegálnych Delfi vytvorenie programu a jeho predaj je taktiež nelegálne. V prípade oficiálneho predaja, musíme mať legálnu verziu vývojového prostredia a najlepšie je byť živnostníkom, aby sme nezabudli na odovzdávanie dane z príjmu (to aby som mal čisté svedomie :).

Vývojový proces

Osobne by som celý vývoj zhrnul do niekoľkých hlavných kategórii:

  1. Analýza - tu spadá jednanie s klientom, vytýčenie toho, čo má a aj nemá informačný systém priniesť, ako funguje celá firma apod.
  2. Návrh - návrh riešenia a hlavne postupu. Tu je vlastne tá naša špecifikácia, ktorá vychádza z informácii analýzy.
  3. Realizácia - zoberie sa špecifikácia a zrealizuje sa to, čo v nej analytik napísal + testovanie v jednotlivých fázach vývoja a záverečné „beta" testovanie, dokumentácia.
  4. Implementácia - program sa zavádza u zákazníka. Tu by mohol spadať aj „poimplementačná" podpora, hotline, dodefinovanie niektorých požiadaviek apod.

Keď sa na tieto tri kroky pozrieme, vidíme, že samotné programovanie nehrá majoritnú úlohu pri tvorbe a do očí udiera aj akási „vrstevnatosť" celého procesu vývoja. Jednotlivé vrstvy sú závisle od tých predošlých. Toto je dôležité si uvedomiť, pretože môže vzniknúť nepekný problém, keď nedorozumenie v analýze spôsobí pád celého projektu až v stave implementácie, keď klient dostane niečo úplne iné, ako očakával.

Preto som osobne robil „všetko" naraz. Počas vývoja som už jednotlivé časti zavádzal u zákazníka, ktorý bol ale upozornený, že neručím za dáta a integritu, resp. spätnú kompatibilitu v prípade finálnej verzie. Takto sa pekne vychytávali muchy z praxe, ktoré mi hlásil sám klient (odbúranie platenia beta testera), klient sa postupne zoznamoval so systémom po jednotlivých častiach a preto som bol aj nútený, aby ma nebombardoval triviálnymi otázkami, súčastne písať manuál k jednotlivým dokončeným častiam. Tento spôsob, ale vyžaduje brutálnu analýzu a návrh, ktorý musí byť natoľko neoblomný, že pri vývoji môže vzniknúť len niekoľko odchýlok alebo anomálii, s ktorými sa na začiatku nerátalo.

Pozrime sa ale bližšie na schému vývoja, podľa ktorej sa môžeme riadiť.

Vývojový proces aplikácie
Obrázok 1. - Vývojový proces aplikácie

Neprehliadnite: