Rok 2000 ve světě informačních technologií

dnes se podíváme na fázi Opravy zdrojového kódu jako na část projektu ošetřování apli-kací pro rok 2000. Jednotliv...


dnes se podíváme na fázi Opravy zdrojového kódu jako na část projektu
ošetřování apli-kací pro rok 2000. Jednotlivé opravné techniky a strategie
budou detailně popsány na konci tohoto seriálu.
Na základě předchozích fází projektu mohou nastat následující možnosti opravy
existujících aplikací:
1. Odstranění nepoužívaného systému v případě rozsáhlých systémů existují malé
aplikace, které mohou být využívány málo, příp. nevyužívány, pokud nejsou
nezbytně nutné pro chod podniku.
2. Náhrada systému tato varianta se jeví zpočátku jako velmi atraktivní. Mnoho
aplikací je relativně "starých" a náhrada novou aplikací se může jevit jako
nejschůdnější. Nicméně náhrada systému může znamenat mnoho práce s implementací
nové aplikace příp. systému a je vhodnější ji naplánovat na jiné časové období,
které není ohrožováno přechodem tisíciletí.
3. Oprava systému představuje zásah do systému tak, aby byl provozovatelný po
roce 2000. Dále proto budeme předpokládat tuto variantu.
V opravné fázi projektu 2000 programátoři opravují zdrojový kód jednotlivých
aplikací s využitím informací získaných ve fázi analýzy a vyhledávání. Opravná
fáze představuje ve své podstatě zásah do procedurálních výrazů zdrojového
kódu, modifikaci struktury databázových definic a dat. Opravu kódu lze provést
manuálně nástroji podporujícími cyklus editování/kompilování/ladění nebo
nástroji automatizujícími opravný proces. V současné době existuje poměrně
dosti nástrojů pro vyhledávání a analýzu zdrojového kódu. Toto však již nelze
říci o nástrojích pro opravu kódu, které mohou být automatizované příp.
poloautomatizované. Poloautomatizované nástroje na opravu kódu interaktivně
komunikují s programátorem a umožňují tak prověřovat, potvrzovat a
přizpůsobovat programátorské aktivity aktuálním potřebám.
Pokud jsou ve fázi analýzy a vyhledávání neopraveného zdrojového kódu
přehlédnuty proměnné, nesoucí informace o datumu, lze je dodatečně
identifikovat ve fázi opravy a testování.
Mosty
Jedním z největších problémů, souvisejících s projekty roku 2000, jsou
aplikace, které neběží samostatně; jsou provozovány v režimu klient/server a
sdílejí společná data. Představme si databázi, jejíž data jsou sdílena dvěmi
nezávislými aplikacemi. Pokud si oprava jedné z aplikací vyžádá úpravu
databáze, bude to mít vliv i na funkčnost aplikace, která nebyla opravována pro
rok 2000. Tuto situaci lze řešit vytvořením tzv. mostu bridge, který izoluje
změny provedené v databázi pro aplikaci, která ještě nebyla opravována. Mosty
"bridges" mohou být dvojího druhu externí a interní. Častěji používané externí
mosty jsou spouštěny před provozem vlastní aplikace, i když jejich nevýhodou je
jistá těžkopádnost. Interní mosty jsou naopak přímo implementovány do
jednotlivých programů.
V souvislosti s opravami zdrojového kódu se také hovoří o znalostech kladených
na programátory. Základním předpokladem je znalost příslušného programovacího
jazyka. V řadě případů je také nezbytná znalost logické části aplikace.
Testování
Testování je velmi důležité fáze, která slouží k ověření funkčnosti a správného
chování aplikace. V porovnání s jinými fázemi projektu je pro testování k
dispozici velmi omezené množství nástrojů. Testování změn, provedených v
existujícím systému, lze rozdělit do tří etap:
Testování programových jednotek způsob testování zaměřený na testování úseků
programů, v nichž došlo ke změnám. Programátor okamžitě po ukončení opravy kódu
použije ladící nástroj (debugger) nebo jednoduchý příklad, kterým vyzkouší
funkčnost opraveného kódu.
Funkční test je zaměřen na testování více funkcí programu. Ve správně
strukturovaném prostředí jsou funkční testy určeny k otestování plné
funkcionality programu identifikované ve specifikaci aplikací. V ideálním
prostředí lze funkční testy plně automatizovat testovacími prostředky,
nevyžadují pak žádný zásah programátora.
Test systému znamená testování aplikací, které mohou být spolu vzájemně
provázány a jsou umístěny do simulovaného prostředí reálného provozu. Cílem je
vyzkoušet provoz aplikace před jejím nasazením do běžného provozu a
identifikovat chyby přehlédnuté v průběhu funkčního testování. Velmi důležitým
bodem je testování aplikace s dalšími částmi produkčního systému komunikačními
vrstvami (middleware), operačním systémem apod. Systémový čas lze v simulačním
prostředí posunout do budoucnosti a tak získat konkrétní výsledky, které nelze
běžně získat v průběhu funkčního testování a testování programových jednotek.
V souvislosti s testováním programů pro rok 2000 jsou všeobecně používány dva
základní druhy testovacích nástrojů:
Datový simulátor umožňuje testování jednotlivých aplikací v budoucím čase bez
zásahu do operačního systému běžícího na stejném počítači. Datový simulátor
zachycuje volání programů manipulujících s datumem a vrací specifickou hodnotu,
která se může lišit od hodnoty získané ze systémového času.
Data Ager program, který zkopíruje soubory příp. databáze, změní nastavení
datumových polí na budoucí dle specifikací programátora, nebo provede tzv.
posun (offset) datových záznamů v originálním souboru.
8 1602 / ram









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.