Počítačem podporovaný vývoj programových systémů

Počítače jsou všude kolem. Obklopují nás ze všech stran. Vidíme např. pécéčko na stole. Je zcela zřejmé, že ele...


Počítače jsou všude kolem. Obklopují nás ze všech stran. Vidíme např. pécéčko
na stole. Je zcela zřejmé, že elektronický zápisník, vznešeně nazývaný
"databanka", není nic jiného, než malý počítač. Jindy je jen tušíme takový
mobilní telefon není nic jiného, než vysílačka řízená počítačem. Mnohdy ani
neregistrujeme, kde všude kolem nás malé počítače jsou. Jsou v soudobých
ledničkách, pračkách mixerech, i v troubě je počítač (v té mikrovlnné).
Čas odvál všechny hřídelky, vačky a relátka. Když konstruktér vytváří nový
výrobek, tak nepřemýšlí, jak vyřešit problém stačí tam dát mikroprocesor a ten
všechno zvládne.
Myslíte, že letadlo řídí pilot? Ne, letadlo řídí několik desítek
mikroprocesorů, pilot je tam jen proto, aby měl kdo nosit elegantní uniformu a
aby letušky měly s kým koketovat (skoro jen proto).
Myslíte, že lokomotivu řídí strojvůdce? Lokomotivu řídí výhybkář a několik
mikroprocesorů, strojvůdce tam je jen proto, aby řekl, kdy se to má rozjet a
kdy zastavit.
Myslíte, že když dupnete na brzdu, brzdíte? Vy? Jestliže ano, pak máte docela
staré auto.
Dokonce když píši tento text, tak mě počítač neustále kontroluje a červeně
podtrhává slova, která se mu nezdají.
Počítače jsou prostě rychlejší a spolehlivější než kterýkoliv člověk. Neunaví
se, nemají soukromý život, nenaštvou se, jsou stále k disposici a stále jsou
ochotné.
Program vdechne počítači život
(Počítač je rychlý idiot)
Počítače jsou skutečně rychlé. Píši na počítači (jinak už ani neumím), ťuknu
jedno písmenko, ťuknu druhé písmenko, dopíši větu a zamyslím se, jak budu
pokračovat. Doba mezi dvěma písmenky to jsou pro počítač staletí! Kdybych
pohled na člověka zploštil tak, že bych měřil jen počet bitů, který za život
vyprodukuje, počítač stejný počet bitů zvládne za několik milisekund (u žen by
se to možná měřilo v desetinách vteřiny).
Počítač skoro nic neumí. Umí jen sčítat bity, to ale velmi rychle. Jinak je
úplný idiot, všechno, co má vědět, všechno, co od něj budeme později chtít,
musíme do něj nejdříve vložit. Počítač ví jen to, co do něj dáme. Jestliže do
počítače uložíme, že tráva je zelená, tak nám bude stále tvrdit že je tráva
zelená, i když je to zjevná nepravda. Na procházce jasně vidíme, že tráva je
hnědá a občas bílá, když je pokryta jíním.
Teprve program vdechne počítači život, všechny vědomosti a dovednosti počítače,
to jsou programy a data, které jsme si koupili od specializovaných výrobců nebo
sami vytvořili. Počítač je jako lednička můžeme si z něj vzít jen to, co do něj
někdo dal.
Ne každý si to uvědomuje. Občas můžete slyšet v rádiu nebo televizi spisovatele
nebo scénáristu, který si stěžuje, že mu počítač něco provedl. Říká "Počítač mi
ztratil poslední verzi knihy", "Počítač to neumí vytisknout", "Počítač odmítl
psát". Jsou to demonstrace vlastní hlouposti. Počítač neumí vůbec nic, správné
stížnosti mají znít takto:
l"Koupil jsem si program a nepřečetl jsem si příručku."
l"Koupil jsem si program na něco jiného než potřebuji."
l"Koupil jsem si program od firmy, která má špatné programátory."
Když někdo neumí používat sekeru a seká dříví, tak se sekne do nohy to je přece
logické a přirozené. Když si pořídím program a neumím ho používat, něco zvořu;
tak už to ve světě chodí. Existují však dobré a špatné programy, existují chyby
v programech musí tomu tak být? O tom si budeme povídat.
Chyby v programech
Shodou okolností zrovna dnes se stala v menze příhoda, veselá nebo smutná
záleží na hledisku, pro účastníky značně denervující.
Na jedné straně pultu byly várnice a kotle s jídlem pro několik tisíc lidí, na
druhé straně pultu bylo několik tisíc hladových studentů. Jídlo se však nemohlo
vydávat, protože zkolaboval počítačový systém evidence zakoupených obědů.
Studenti se nakonec najedli (v naší civilizaci hodina hladovění spíše prospěje
než uškodí), chyby programů však způsobují i daleko větší škody. Všeobecně
známé jsou případy dvou sond, americké Mariner a sovětské Věněry, které
nesplnily své úkoly a ztratily se ve vesmíru. Přišlo nazmar několik milionů
dolarů a rublů. Důvodem byla programátorská chyba. V americkém případě
programátor ve fortranském programu napsal tečku místo čárky. Dost malicherná
chyba vedla k obrovské škodě.
Stávají se i horší věci. Mnoho nevysvětlených leteckých katastrof se přičítá
chybám programových systémů. U některých je to prokázáno. Třeba jeden pilot v
nepřehledné situaci prudce trhl kniplem tak prudce, že zmátl programový systém,
který předal informace o poloze kniplu v jiném pořadí. Letadlo zamířilo k zemi,
místo aby zdvihlo nos. Programátorská chyba stála 140 lidských životů.
Proč jsou v programech chyby? Protože programátoři špatně pracují zní povrchní
odpověď. Je to skutečně povrchní pohled. I dobří programátoři dělají chyby.
Skutečný problém je jinde programy (spíše programové systémy) jsou složité,
příliš složité, než aby je bylo možné zvládnout bez potíží.
Co říkají statistiky?
O programátorech:
Mezi programátory jsou obrovské rozdíly v produktivitě práce. Až 1 : 20.
O programových systémech:
31 % všech softwarových projektů je zastaveno, aniž by byly dokončeny dle
zadání (81 miliard dolarů).
Více než 70 % zbývajících je dodáno, aniž by splnily očekávání zadavatelů.
Průměrný projekt je dokončen za 189 % plánovaných nákladů a 222 % plánovaného
času.
Jen 9 % velkých projektů bylo dokončeno včas a za plánovanou cenu.
Jen 16 % projektů v malých firmách bylo dokončeno včas a za plánovanou cenu.
Závěry ze statistik:
Je zřejmé, že produktivním programátorem se může stát jen člověk s určitými
mentálními a psychologickými předpoklady pro tuto práci. Některé předpoklady
jsou zřejmé:
lrozvinutá schopnost analýzy a syntézy,
lschopnost přejít z jedné úrovně podrobnosti na jinou, pracovat na ní a zase se
vrátit na předchozí úroveň. Takto přecházet mezi čtyřmi až pěti úrovněmi.
Ze statistik o programových systémech lze usoudit, že neznáme metodiky práce
pro zvládnutí tak složitých věcí, jako jsou programy. Považuji za užitečné
podívat se, jaké metodiky máme k disposici a jak se k nim došlo.
Jak se vyvíjejí techniky programování
Necháme stranou základní počítačové inovace, jako je von
Neumannův princip, vytvoření instrukcí strojového kódu a oddělení profesí
technik a programátor. Na úsvitu počítačových dějin se formulovaly 2 základní
principy, které tvoří základ programování dodnes:
lprogramátor nevytváří programy ve strojovém kódu,
lprogramy se člení na uzavřené a dost samostatné části.
Podprogramy
Podprogram je relativně samostatné a relativně uzavřené řešení dílčího
problému. Podprogram se vyvolá z hlavní části programu, vyřeší svůj dílčí
problém a výsledky předá hlavní části programu. Hlavní výhody podprogramu jsou
dvě: (1) člení velký problém na několik menších problémů, (2) jeden podprogram
je použitelný v různých programech, ve kterých je potřeba vyřešit stejný
podproblém.
Překladače
Programátor formuluje řešení svého problému v programovacím jazyce, který je
přizpůsoben jeho potřebám (občas se jazyk programování označuje jako
symbolický jazyk). Pak nastoupí překladač, který tento program v symbolickém
jazyce mechanicky převede do strojového kódu počítače. Teprve po úspěšném
dokončení překladu může počítač tento program provést.Éra jazyků
Převládal názor, že všechny potíže tvorby programových systémů se vyřeší novými
programovacími jazyky. Byly vytvořeny desítky programovacích jazyků různé
úrovně. V jednom výčtu (paní Samettová) bylo napočítáno asi 200 programovacích
jazyků (a to byly brány v úvahu jen ty, které používal ještě někdo jiný než
autoři jazyka). V podstatě se používaly 2 cesty jednak specializované jazyky,
jednak se hledal nejlepší univerzální programovací jazyk. Na obr. 1 je schéma
vztahu mezi překladačem a překládaným programem. Přípravné akce (překlad) jsou
označeny čárkovanými šipkami, používání programu má šipky plné. Jedná se o
dávkový překlad a interakční program.
Tehdy se ukázaly 3 základní koleje, po kterých běží vývoj programování dodnes:
lvnořování vrstev,
lspecializované nástroje,
lmetodiky programování.
Vnořování vrstev
Složitější algoritmy se vydělovaly do podprogramů. Pokud se takový algoritmus
používal často a byl dostatečně obecný, vnořil se do základnějších vrstev
počítačového systému. Stal se např. příkazem v programovacím jazyce, nebo se
ponořil až na úroveň operačního systému. Některé algoritmy se staly součástí
firemního vybavení (klesly až na úroveň instrukcí nebo technického vybavení).
Příklady: programovací jazyk COBOL má příkaz SORT, komunikace s vnějšími
paměťmi (koncept souborů) se stala součástí operačních systémů, aparát
"zásobník" je součástí stolních počítačů (PC).
Specializované nástroje
Jiný způsob osamostatnění algoritmu je vznik specializovaného nástroje. V
podstatě se jedná o velmi specializované programovací jazyky, kde editor,
překladač i výsledný program tvoří jeden celek.
Příklady: databázový systém, tabulkový kalkulátor.
Metodiky programování
Základní metodikou programování je, byl a také bude hierarchický rozklad.
Hierarchický rozklad používá člověk při všech problémech, které jsou pro
jedince příliš složité. Pro účely programování byl obecný hierarchický přístup
modifikován na následující techniky:
lkoncept dobře strukturovaných programů,
lmodulární programování,
lprogramování ve vrstvách.
Krátce si tyto pojmy vysvětlíme.
Hierarchický rozklad
Je to logický rozklad úlohy na části a ty se zase dělí na podčásti tak dlouho,
až se dojde k podčástem, které je jednoduché programovat. Podrobněji:
Mějme úlohu U, která je příliš složitá, abychom ji bezprostředně zvládli.
Rozložíme úlohu U třeba na 3 podúlohy, na U1, U2 a U3. Tím jsme 1 složitý
problém rozložili na 4 jednodušší problémy:
1. realizace U1,
2. realizace U2,
3. realizace U3,
4. spojení U1, U2 a U3 v jeden celek, který vyřeší celkovou úlohu U.
Jestliže některá z podúloh je zase příliš složitá, tak ji také rozložíme na
podúlohy nižšího řádu...
Je zapotřebí si uvědomit, že když se říká "hierarchický rozklad", označuje se
tím jedna strana postupu a nerozlučně k tomu patří i druhá strana hierarchická
syntéza. Původně jednotná profese "programátor" se tak rozštěpila na dvě
profese (viz obr. 2):
lanalytik, který prováděl hierarchický rozklad a dával směrnice pro syntézu,
lprogramátor, který realizoval jednotlivá řešení a prováděl syntézu.
Koncept dobře strukturovaných programů
Také se říká "strukturované programování". Jeho podstatou je, že rozklad úlohy
na podúlohy se omezuje pouze na 3 konstrukce na sekvenci, selekci a iteraci a
žádné jiné konstrukce rozkladu nejsou použity.
Sekvence: úloha se rozloží na podúlohy, které se provádějí postupně za sebou.
Příklad: kvadratickou rovnici vyřeším, když nejdříve vypočtu diskriminant a pak
vypočtu kořeny.
Selekce: úloha se rozloží na 2 (nebo několik) podúloh, úloha se vyřeší tím, že
se provede právě jedna podúloha (v závislosti na nějaké podmínce). Příklad: v
závislosti na hodnotě diskriminantu počítám buď reálné nebo komplexní kořeny.
Iterace: řešení úlohy sestává z opakovaného provádění podúlohy. Příklad: chůze
je iterace kroků.
Tento koncept je vhodný pro větší kompaktní programy. Konstrukce rozkladu
odpovídají řídicím konstrukcím programovacích jazyků, takže syntéza je
jednoduchá těžiště práce leží na tom, kdo provádí rozklad.
Ze strukturovaného programování mimo jiné vyplývá programátorská zásada:
nepoužívat příkaz GOTO.
Modulární programování
Modulární programování nedává pravidla pro samotný hierarchický rozklad, určuje
však, jak má vypadat výsledek. Předpokládá, že výsledkem rozkladu je systém
modulů, které jsou rozčleněny do podsystémů (viz obr. 3). Je to hierarchický
přístup, moduly jedné úrovně lze chápat jako podsystémy nižší úrovně, které
jsou zase složeny z modulů nižší úrovně.
Zavádí se 2 pojmy:
lsoudržnost je intenzita vazeb mezi moduly v rámci jednoho podsystému. Na obr.
to jsou např. vazby A-D nebo R-P.
lspřaženost je intenzita vazeb mezi moduly různých podsystémů. Na obr. to jsou
vazby P-A nebo Q-B.
Pro soudržnost i spřaženost se intenzita vazeb člení do kategorií. Cílem
modulárního programování je mít co největší soudržnost a co nejmenší
spřaženost. Za moduly a podsystémy můžeme považovat v podstatě cokoliv, pro
pochopení si můžete představovat podsystémy a moduly jako podprogramy různých
úrovní. Přestože modulární programování lze použít na kterékoliv úrovni,
převážně se používá pro nekompaktní programy, tj. vede k programovým systémům
složeným z většího množství samostatně překládaných částí.
Z modulárního programování vyplývají programátorské zásady:
lmálo používat globální proměnné,
lpodprogramům předávat všechny údaje pomocí parametrů.
Programování ve vrstvách
Je to také určitá modifikace hierarchického rozkladu. Předpokládejme, že úloha
má poskytovat určité rozhraní nazvěme jej "Jazyk A". Na druhé straně výpočetní
systém poskytuje základní rozhraní (poskytuje určité služby v určitém tvaru),
toto základní rozhraní nazveme "Jazyk Z".
Transformace požadovaných služeb jazyka A na nabízené služby jazyka Z je příliš
složitá. Proto se nadefinují mezijazyky (vložené jazyky), např. B a C. Místo
aby se řešila jedna složitá transformace A-Z, tak se řeší 3 jednodušší dílčí
transformace A-B, B-C a C-Z.
Programování je dostih
Dosavadní výklad vypadá tak, že existují úlohy určité složitosti a programátoři
pořád ne a ne se strefit, aby je uměli vyřešit. Ve skutečnosti je programování
dostih. Před programátory stojí úlohy určité složitosti. Programátoři vyvinou
techniky anebo metodiky pro řešení úloh tohoto typu a složitosti. Když
programátoři tyto pomůcky zvládnou, přestanou být dosavadní úlohy zajímavé a
požadují se úlohy jiného typu a řádově větší složitosti.
Technika (tedy programátorská technika) je návod, jak v konkrétních podmínkách
vyřešit konkrétní dílčí problém. Soubor na sebe navazujících technik je
technologie (technologický předpis).
Metodika je návod, jak přistupovat k řešení problému. Metodika je abstraktní,
jsou to (někdy dost vágní) doporučení, technika je konkrétní, šitá na určitou
situaci. Samozřejmě není mezi oběma pojmy ostrá hranice, každá úspěšná metodika
je transformována na postup, ve kterém se doporučuje používat určité techniky
(a použití jiných se zavrhuje). Takový metodický postup se začíná podobat
technologickému předpisu. Oboje se skládá z jednotlivých technik, metodika je
volně doporučuje, technologický předpis je stroze vyžaduje. Možná by se také
dalo říci, že technika říká jak to udělat, kdežto metodika říká proč to dělat.
Je žádoucí, aby z metodiky vyrostla technologie. V programování se však dosud
vždy stalo, že když se k přerodu metodiky do technologie schylovalo, změnily se
podmínky a požadavky a bylo třeba řešit něco jiného.
Někdy v tom je i trocha lidské tragédie. Jeden můj kolega vytvořil systém pro
tvorbu agend pro sálové počítače (agendou se tehdy chápal potištěný pás papíru
z tiskárny, dlouhý nějakou desítku metrů, ve kterém bylo vše, co mohlo vedení
podniku zajímat). Když byl tento agendový systém hotov a mohl jít k uživatelům,
my jsme již dávno pracovali na terminálových sítích a uživatelé o nový systém
na agendy neprojevovali zájem. Takových příkladů lze uvést řadu.
Specializace metodik
Rozvoj programovacích jazyků i rozvoj programovacích technik (nejdůležitější
jsou zmíněny výše) přinesl význačný pokrok, nevyřešil však základní problém že
totiž složité úlohy jsou neudržovatelné a v podstatě neodladitelné. Převládl
názor, že chyba není v používaných prostředcích, ale v nedostatečných
metodikách. Nejdůležitějším poznatkem je, že selský rozum zvládá jen relativně
jednoduché úlohy, že bez formulované metodiky a bez výcviku v jejím používání
nelze zvládnout tvorbu složitých systémů.
Hierarchický rozklad se nejvýrazněji specializoval ve 2 směrech, jako:
lfunkční rozklad,
ldatový model.
Funkční rozklad
Vznikly metodiky funkčního rozkladu a jim odpovídající
techniky, např. DFD (diagramy datových toků), JSP (Jacksonovo strukturované
programování), TSP (Technologie strukturovaného programování).
Jedním z důležitých podnětů byly statistiky o nákladech na velké systémy (viz
obr. 5 ). Ze statistik vyplynuly 2 dodnes platné závěry:
lNejvíce se dá ušetřit na údržbě (aktualizaci a opravách) programových systémů.
lJestliže se vyvíjí tlak na zkrácení tvorby programů (na jejich návrh a
implementaci), tak celkové náklady rostou.
Od těch dob se metodiky soustředí (kromě jiného) na dosažení přehlednosti,
dobré dokumentace apod. Pro firmy je důležité, aby byly možné zásahy do
programu i při fluktuaci programátorů.
Pro programátory z toho plyne zásada: Přehlednost a čitelnost programu je
důležitější než jiné vlastnosti.
Hierarchický rozklad se osvědčil v rámci programů (jednotlivých procedur,
logicky spojených skupin procedur), v rámci programových systémů se osvědčil
jen zčásti. Zavedl totiž pořádek v procesní (funkční) složce programů, data
však zůstávala neuspořádaná.
Datový model
Paralelně s funkčním hierarchickým rozkladem vznikala teorie datového rozkladu,
který vedl k velmi progresivnímu vývoji programování. Nejprve se formuloval
síťový a hierarchický model. Pak plně opanoval pole velmi jednoduchý relační
model, dokonce do té míry, že pod datovým modelem se nyní skoro automaticky
rozumí relační model.
V relačním modelu se definují entity a jejich vztahy (Chenův nebo E-R model).
Tento rozklad je hierarchický pouze omezeně zahrnuje jen 3 úrovně. Nejnižší
úroveň je údaj číslo nebo text. Údaje se sdružují do záznamů (pro germanofily
do vět), záznamů téhož typu je vždy více. Takové množině záznamů jednoho typu
se říká entita. Jinou terminologií: entita odpovídá tabulce, záznam řádku
tabulky a údaj odpovídá sloupci tabulky.
Podnětem byly úlohy s datovou složitostí kdy organizace dat byla větším
problémem než algoritmy (nebo algoritmy již byly dobře známy). U takových úloh
se ani tak nejedná o výpočet, ale o zpřístupnění dat. Jediné složitější jsou
algoritmy pro třídění a vyhledávání a ty jsou dnes známy skoro dokonale.
Je velké procento úloh, u kterých se to osvědčilo a rozvoj databázových systémů
tyto úlohy podstatně zjednodušil. Zůstává ale hodně úloh, které vedou k
potížím.Éra metodik
Ukázaly se dva důležité poznatky:
1. Pouhý hierarchický rozklad, ať tak nebo onak specialisovaný, nevyřeší
problémy návrhů systémů. Je zapotřebí najít něco nového.
2. Návrh systému je zapotřebí rozčlenit do několika etap, ve kterých jde po
každé o něco jiného.
Členění návrhu systému do etap se ustálilo na tyto etapy:
lanalýza vzniká logické řešení problému, bez ohledu na prostředí, ve kterém
poběží, a bez ohledu na způsob, kterým bude systém realizován. (V datovém
rozkladu to je normalizace datového modelu, tj. odstranění jakékoliv
redundance.) Heslovitě to lze vyjádřit tak, že u logického modelu nezáleží na
tom, jestli výsledek poběží na Windows nebo ne.
ldesign přizpůsobení logického řešení provozním podmínkám. (U datového modelu
to obvykle znamená zavádět redundanci, protože rozsáhlé normalizované databáze
mívají neúnosnou dobu odezvy.)
l implementace teprve v této etapě se systém skutečně vytváří tj. programuje.
Zkratkovitě řečeno, nejdříve se rozhodneme, co se bude dělat (analýza), pak se
určí jak se to bude dělat (design), a teprve pak se to udělá.
Podstatou toho všeho je, že je zapotřebí vyřešit samotnou logiku úlohy, že je
třeba porozumět požadavkům, určit, co se vlastně chce. Je zapotřebí získat
určitý globální nadhled, mít přehled o celkových cílech a o cestách, jak jich
dosáhnout. Je třeba mít přehled nejen o cestách, kterými se bude ubírat řešení,
ale i o cestách, které nebudou použity a proč nebudou použity. To všechno je
analýza.
Bez slušně udělané analýzy se vytvoří změť dílčích řešení, která spolu
nespolupracují, nebo také pracují proti sobě, práce jednoho dílčího řešení
zruší práci jiného.
Oproti tomu i sebelépe udělaná analýza není ještě vytvořený systém. Bez
kvalitní implementace, která nic nezanedbá, která řeší celý problém v jednotném
duchu a která vyvažuje jednotlivé protichůdné požadavky tak, aby systém byl
optimálně řešen, bez takové implementace nemůže být systém úspěšný.
Problém implementace úlohy řeší strukturované programování (Dijkstra a Jackson)
a další programovací techniky. Problémy analýzy řeší metodiky, v prvé řadě
strukturované metodiky.
Strukturované metodiky
Funkční i datový rozklad mají doplňující se výhody a nevýhody, bylo potřeba je
nějak sjednotit. Nepřišlo se na nic lepšího než na to, že se budou vytvářet
paralelně a stále se budou během této tvorby porovnávat. Tak vznikla naše další
zbraň proti složitosti porovnávání modelů.
Je to podobná myšlenka, která se s úspěchem používá např. ve strojírenství,
architektuře i jinde. Jako plán budoucího trojrozměrného výrobku (součástky
nebo domu) mám několik dvourozměrných plánů nárys, bokorys, půdorys.
Rozdíl oproti programování je asi v tom, že složitost informačního systému lze
charakterizovat více než třemi rozměry.
Návrh informačního systému se tak stává dvojúrovňovým procesem:
lÚroveň modelů. Systém se nenavrhuje jako celek, ale vytváří se několik modelů
(pohledů), každý model si všímá některých aspektů a jiné opomíjí.
lJednotlivé modely se vytvářejí pomocí hierarchického rozkladu (obvykle).
Podstatou použití modelů je to, že jeden model podrobně rozpracovává některé
aspekty systému a jiné aspekty opomíjí. Druhý model rozpracovává tyto opomíjené
aspekty a opomíjí některé aspekty rozpracovávané prvým modelem. Je nutné, aby 2
modely měly některý rozpracovávaný aspekt společný, aby je bylo možno
porovnávat to znamená, aby změna jednoho modelu ovlivnila model druhý.
Kolem strukturálního návrhu bylo vykonáno mnoho metodické práce, ať již v
návrzích různých modelů a dílčích modelů (v některých metodikách jejich počet
přesahuje desítku), tak v celkových zásadách práce. Následuje výčet
nejvýraznějších charakteristik:
letapizace návrh informačního systému byl rozdělen na několik etap, každá je
charakterizována určitým dílčím úkolem. Jsou to: formulace zadání (praxe
ukazuje, že na smysluplnosti zadání záleží osud systému), analýza (tvorba
logického řešení, tj. esenciálního modelu navrhovaného systému), design
(vytvoření zadání pro implementátory), implementace (vlastní tvorba systému,
tj. jeho naprogramování), testování, předání do provozu a provoz.
lnávrat v postupu i když metodiky obsahují jisté prvky sebekontroly, je nutné
do nich zařadit možnost kdykoliv se z jedné etapy vrátit zpět a opravit nebo
upravit část předchozí etapy nebo etap.
lnejasný design většina metodik je dobře propracovaná v etapě analýzy a dosti
na rozpacích v etapě designu. Utíkají se k takovým nemetodickým popisům, jako
jsou stromy volání procedur, nebo se snaží použít strukturované programování
(určené pro jednotlivé moduly) jako prostředek mezimodulového návrhu řízení.
Někdo kdysi pejorativně označil strukturální metodiky jako "vodopádový model" a
někteří kritici tuto asociaci berou doslovně a tvrdí, že je zakázáno vracet se
do již ukončených etap. Strukturální metodika to naopak doporučuje, na druhé
straně je třeba připustit, že tyto metodiky, se svým velkým množstvím navzájem
provázaných modelů, působí poněkud neohrabaným dojmem a člověk se instinktivně
takovému návratu vyhýbá.
CASE počítačem podporovaný vývoj programových systémů
Všechny metodiky se ukazují jako neúčinné, jestliže jsou prezentovány pouze
jako idea pouze jako textový postup. Snad je lépe říci jako papírový postup.
Metodiky vznikaly i dříve, zůstávaly však omezeny na okruh svých autorů.
Uvažujme jako příklad třeba tvorbu rozsáhlejšího datového modelu. To je několik
set údajů členěných do několika desítek entit. V tomto množství musíme
zajistit, aby dva různé údaje neměly stejné jméno, a současně musíme zajistit,
aby údaje, které jsou stejné smyslem, měly také stejné jméno. Pokud to
nezajistíme, vzniknou chyby již v logickém návrhu.
Na druhé straně, člověk je zařízen tak, že dobře vnímá dvojrozměrné obrázky.
Proto se všechny složitější věci (nebo věci, které je třeba vnímat rychle)
reprezentují v grafické formě. Když se nad tím zamyslíte, uvědomíte si, že ve
vašem okolí je mnoho příkladů. Statistici, ekonomové, manažeři, ti všichni
používají grafů k reprezentaci i třeba jednoduchých tabulek. Prvotní tvar
jízdního řádu na železnici je graf, jízdní řád ve formě knížečky je z tohoto
grafu odvozen. Snad všichni jsme si svůj školní rozvrh hodin kreslili jako
různě vybarvované čtverečky.
Aby jakákoliv metodika měla možnost uplatnit se v praxi, musí mít svou
grafickou reprezentaci. Udržet grafickou reprezentaci systému konzistentní se
seznamy několika set prvků, bez opomenutí a chyb, to jen s tužkou a papírem
nejde.
Éra metodik mohla nastat, když byly splněny dvě hlavní podmínky:
lbyly rozšířeny počítače s možností grafického výstupu (což splnila pecéčka),
lřídicí pracovníci uznali důležitost analýzy do té míry, že investovali do její
programové podpory.
Rozšířily se pouze ty metodiky, které byly podporovány systémy CASE (Computer
Aided Software Engineering). Sám jsem zažil několik metodik, jejichž podpora
byla orientována na textové terminály (např. R-systém), a metodiky napsané
erudovanými autory, kteří však nebyli schopni vytvořit programovou podporu
(např. HIT). Použití těchto metodik zůstalo omezeno na autory, jejich blízké
přátele a podřízené.
Metodiky nastoupily, když začala odeznívat éra velkých programovacích jazyků.
Tomu odpovídalo i jejich přijetí v programátorské veřejnosti. Čekalo se od
nich, že budou generovat programový systém podobně, jako překladače
programovacích jazyků generují program. Schéma takového očekávaného
generujícího systému je na obr. 8. Očekávalo se, že systém CASE bude schopen z
logického modelu generovat programový systém.
Tato očekávání se ukázala lichá. Všechny generující CASE byly tak
specializované, že se hodily jen pro řešení úzkých oblastí. Všechny CASE, které
pokrývaly široké oblasti, byly bez generace, resp. obsahovaly jen některé dílčí
generace.
Důvody neúspěchu generujících CASE (za neúspěch považuji to, že jsou vhodné jen
pro úzký okruh úloh) jsou celkem nasnadě. Analytik v etapě analýzy vytváří
logický model, který odpovídá na otázku co se řeší. Pro generaci je zapotřebí
jiný model, implementační, kde je určeno také jak se to má řešit a kde jsou
obsaženy různé programátorské finty zvyšující efektivnost. Soustředit v jednom
modelu vlastnosti logického modelu (co se řeší), designového modelu (jak se to
má řešit) i implementačního modelu (efektivnost provozu) znamená popřít vlastní
smysl metodiky a vrátit se zpět řešit celý systém najednou.
Ukazuje se totiž, že převodu z logického modelu do fungujícího programového
systému se musí účastnit lidská inteligence v alespoň dvou dalších
specializacích designérské a programátorské.
Základní myšlenka CASE je znázorněna na obr. 9. CASE je programový systém,
který podporuje určitý typ práce na obr. 9 podporuje práci analytika. Úlohou
CASE je umožnit rozumné grafické zobrazení modelu, vést evidenci všech
používaných prvků a udržovat konzistenci jednak mezi evidovanými prvky
navzájem, jednak mezi prvky a grafickými zobrazeními. Přechod z jedné etapy
projekce do další je přechod z jednoho modelu do druhého to se bez lidské
účasti neobejde, mají-li mít modely smysl. Tak např. na obr. 9 šipka mezi
"CASE" a "programátorem" zahrnuje veškerou designovou činnost a tvorbu
implementačního modelu.
Předchozí odstavec popisuje základní schéma CASE. Současné systémy jej
rozvíjejí v několika směrech.
Systémy CASE podporují několik etap návrhu systému
Moderní systémy CASE tvoří souhrn podpor pro několik etap návrhu systému. Kromě
etapy analýzy a designu jsou to etapy pro rozbor zadání a úvodní studie. Někdy
také obsahují podporu pro tvorbu implementačního modelu např. prostředek pro
tvorbu strukturogramů.
Trochu tu působí potíže terminologie. Vývoj systému lze zjednodušeně pokládat
za posloupnost modelů. Analýza vytváří logický model (někdy se také říká
esenciální), design vytváří designový model, v implementaci se vytváří
implementační model. Každý z těchto modelů sestává z několika pohledů, kterým
se také říká modely. Tak např. logický model strukturované analýzy je tvořen
datovým modelem a funkčním modelem. Jestliže slyšíme obrat "model systému",
musíme z kontextu usoudit, oč se vlastně jedná.
Systémy CASE generují části programů
Myšlenka generovat program z modelu stále okouzluje mnoho tvůrců systémů CASE.
V předchozím textu byla uvedena filipika proti generování, rozumí se tím to, že
generování nesmí být hlavní účel systému CASE. Na druhé straně, jestliže se
CASE soustředí na tvorbu modelu a je možno ušetřit lidskou práci tím, že se z
údajů uvedených v modelu generuje část programu, tak proč toho nevyužít. Navíc
bylo již dosaženo některých úspěchů.
Mnoho CASE má možnost generace struktury relační databáze z datového modelu.
Jinými slovy, jestliže E-R model doplníme implementačními vlastnostmi údajů
(typem a rozsahem), tak je možno vygenerovat sekvenci SGL příkazů, které
vytvoří potřebnou databázi (přesněji řečeno kostru databáze vytvoří strukturu
tabulek, ale už ne spouště apod.).
Podobně bývá často možnost generovat kostru programu, tj. vygenerovat hlavičky
procedur, nebo, u objektově orientovaných CASE, hlavičky tříd a metod.
Některé systémy CASE umožňují převody (překlady) jednoho modelu na jiný např.
překlad logického modelu na designový.
Všechny tyto prostředky jsou užitečné, jestliže se používají s mírou. Musíme si
však uvědomit, že vždy mají následující vlastnosti:
lšetří lidskou práci,
lnutí dávat designové a implementační prvky do modelů, kde nemají co dělat,
lznemožňují nebo znesnadňují účast lidské inteligence při tvorbě modelu nebo
programu.
Prototypování
Je to postup, kdy se na základě požadavků udělá systém, který zhruba vyhovuje
požadavkům uživatele. Předvede se a uživatel se na něm nechá nějakou dobu
pracovat. Upraví se podle připomínek a znovu se předvede. Opakuje se to do té
doby, kdy k systému nejsou připomínky.
Je zde použita skoro výhradně jen iterace naše zbraň proti složitosti.
Aby bylo možné použít prototypování úspěšně, musí být splněny 2 podmínky:
lMusí být k dispozici prostředky, které umožňují výběr již hotových polotovarů
(již vyřešených algoritmů) a jejich spojování. Takovým prostředkům se obvykle
říká 4GL (Four Generation Language for Business Processing). V současné době
tyto prostředky nabývají objektového charakteru, jsou představovány "buildry" a
objektovými knihovnami.
lŘešená úloha musí být z logické stránky jednoduchá a musí obsahovat jen takové
problémy, které jsou ve 4GL vyřešeny.
Časté bývá spojení 4GL a databázového systému takovým prostředkem lze vyřešit
většinu nepříliš složitých úloh.
Pokud snesete lehčí pohled na problematiku, přečtěte si následující odstavec:
Vývoj auta prototypováním
Uživatel chce prostředek pro cestování vytvoříme pro něj koloběžku. Uživateli
se nelíbí vratkost dopravního prostředku uděláme šlapací autíčko. Uživatel si
stěžuje, že ho bolí nohy a prší na něj přidáme motocyklový motor a střechu dali
jsme mu hadraplán. Uživatel si stěžuje, že se mu smějí, přidáme čtvrté kolo a
šasi z mercedesu.
Aby prototypování bylo smysluplné, musí se jednat o velmi průhlednou a
jednoduchou úlohu, nebo někde musí být designový model. Často ho mívá
konstruktér v hlavě. Jestliže konstruktér řeší jednu a tutéž úlohu často (pro
různé podniky), pak má problematiku do té míry zažitou, že nosí logický a
designový model v hlavě a může nový systém zdánlivě střílet od boku. Musí se
ovšem jednat o relativně jednoduchou úlohu, těžko si lze představit, že se
takhle střílením od boku vytvářejí
např. nové kompilátory.
Při úvahách tohoto typu je dobré si uvědomit rozdíl mezi počtem úloh a mezi
počtem typů úloh, a také co lze považovat za jednoduchou úlohu.
Trh v určitém okamžiku obvykle vyžaduje vytvořit velké množství úloh jednoho
typu. Velikost podílu může být překvapující, například 70 %, na všechny ostatní
typy úloh zbývá 30 %. Softwarové firmy vyvíjejí prostředky různého druhu na
podporu těchto převládajících úloh protože zde je největší odbyt. Tyto
prostředky sice řeší velký počet úloh, ale z hlediska typů úloh pokrývají jen
malé procento ten jeden typ a podobné úlohy, které se dají na tento typ převést.
Pro tento typ módních úloh je k dispozici tolik prostředků, že je prototyping
velmi účelným postupem. V současné době to jsou úlohy pro evidenci dat. Od
takových úloh se vyžaduje na jedné straně aktualizovat datovou základnu, na
druhé straně vyhledávat jednotlivé údaje nebo poskytovat různé přehledy,
tabulky a grafy. Takový systém je možno vyřešit za použití moderního
databázového systému a tzv. "builderu", tj. systému, který jednak poskytuje
prezentaci dat, jednak dokáže komunikovat s databázovým systémem. Pro úlohu
tohoto typu můžeme vytvořit systém, aniž by bylo nutno naprogramovat byť jen
jeden příkaz.
U takových módních úloh se prověří nejrůznější algoritmy, ty nejvhodnější se
stanou standardy (například se začnou vyučovat). Nejvhodnější podpůrné
prostředky přejdou do obecného repertoáru projektantů a tyto úlohy se začnou
považovat za "jednoduché", tj. za snadno řešitelné úlohy. Trh postaví nové
požadavky a problémem se stanou úlohy jiného typu.
To musíme mít na mysli, když říkáme (nebo slyšíme) "metodika pokrývá úzký okruh
úloh". Přesto v určité době může tato "úzká" metodika co do počtu úloh pokrývat
většinu požadavků trhu. Ovšem její důležitost je omezena, po změně požadavků
trhu upadne v zapomnění.
Z tohoto hlediska nelze prototyping doporučit jako vhodnou součást obecných
metodik, ovšem za určitých podmínek to je velmi účinný prostředek.
Prototypování používají lidé, které lze zhruba rozdělit do následujících typů:
lŘešitelé úloh, kteří mají k dispozici široký repertoár vhodných podpůrných
prostředků v tom smyslu, jak jsme o tom mluvili v předchozích odstavcích.
lLidé, jejichž zásadou je: "Pořádek je pro blbce, já, inteligent, zvládnu
chaos." Výsledky takového použití prototypování jsou velmi různorodé.
lA nakonec ti, kteří používají prototypování jako doplňující prostředek některé
metodiky (ať již strukturální nebo objektové).
Toto poslední použití je v poněkud jiném smyslu, než bylo diskutováno v
předchozích odstavcích. Místo slova "prototypování" by bylo lépe použít obratu
"ověření postupu pomocí prototypu".
Ověření postupu pomocí prototypu
Vytvářený systém prochází během svého vzniku mnoha stavy, kterým říkáme modely.
Jejich přibližný výčet je tento:
lpředprojektové modely (strategické),
lmodel zadání nebo model úvodní studie (černá skřínka),
llogický model,
ldesignový model,
limplementační model,
lprogramy.
Takový postup vypadá hezky a promyšleně, má však jednu vadu: nelze během
postupu dobře ověřit, jestli je vytvářený systém správný, jestli postupujeme
správnou cestou. Teprve když je systém ve formě programů, lze ověřit jeho
správnost. To je velká nepříjemnost. Jestliže v raných fázích dojde k chybě,
táhne se tato celým zbývajícím postupem. Odstraňování chyby, která se zjistí až
v naprogramovaném systému, je drahé. Situaci lze zlepšit tím, že během práce
vytváříme prototypy, na kterých si ověřujeme správnost postupu.
Celý postup se dost liší od toho, co je popisováno v kapitole "Prototypování".
Odlišnost je v cílech a postupech, prostředky se často používají stejné.
Účelem prototypu je prověřit část logického nebo designového modelu. Jako
východisko se vezme část modelu a pak to je vlastně normální postup návrhu
systému. S několika výjimkami. Nesledujeme hledisko efektivnosti. Používáme
různé usnadňující pomůcky (builder a podobně). Dá se říci, že celý návrh
prototypu odbýváme, samozřejmě kromě sledovaného rysu. Na trhu je výběr pomůcek
pro tvorbu prototypu, mnohdy jsou součástí systému CASE.
Nejčastěji se dělá prototyp uživatelského rozhraní, aby se ověřilo, že
zadavatel skutečně ví, co chce. Takový prototyp vypadá jako vytvořený systém,
ale není za ním žádná datová základna. Uživatel může manipulovat s okny,
zadávat údaje ty se ale nikam neukládají, může zadat vyhledání údaje neobjeví
se mu data, ale zabudované konstanty.
Prototypem se mohou sledovat různé rysy, např. lze vytvořit prototyp pro
zjištění rychlosti komunikace na počítačové síti s daným typem a rozsahem dat a
v určité denní době. Podle výsledků pak můžeme určovat nutnost optimalizace
skutečného systému.Objektově-orientovaný přístup k programování
V jedné oblasti programování, v oblasti simulace reálných systémů, se zrodily
první vlastnosti objektů (programovací jazyk Simula) a princip řízení
událostmi. Velmi rychle se rozšířil do oblasti programování vůbec a získal tam
velký úspěch. Důvody jsou přibližně tyto:
Objektový přístup umožňuje daleko lepší využití kódu než knihovny procedur.
Knihovny tříd podstatně zvyšují znovupoužitelnost již jednou naprogramovaných
sekvencí příkazů.
Použitím principu řízení událostmi a objektovým přístupem se elegantně zvládly
prostředky zajišťující "okenní" rozhraní systémů (Windows, Turbo Vision).
K tomu přistupují dva trochu skrytější faktory. Prvním z nich je to, že řešené
úlohy změnily svůj charakter. Z původně většinou dávkových úloh se staly úlohy
převážně interakční. Funkce (procedura) má vždy 1 vstup a k němu příslušný 1
výstup. Znamená to, že funkce reaguje pouze na 1 podnět, a to vždy na stejný
podnět
stejně. S objekty to je jinak. Objekt může reagovat na více různých podnětů, na
každý jinak. Navíc může mít různé reakce i na tentýž vstup objekt si může
pamatovat svou minulost.
Druhý skrytý faktor je metodický. Metodici programování vymysleli mnoho různých
doporučení a zásad, které charakterizují správné způsoby programování a jejichž
dodržování snižuje pravděpodobnost chyb v programu. Jsou to např. abstraktní
datové typy, skrývání informací,
minimalizace spřaženosti apod. Všechna tato doporučení byla převážně verbální a
měla malou účinnost. Většina těchto zásad je nyní skryta v definici tříd a v
objektovém přístupu a jsou součástí objektových programovacích jazyků. Porušení
mnohých těchto zásad je rozpoznáno jako syntaktická chyba a programátor ji chtě
nechtě musí opravit.
Velký úspěch objektů v programování vedl k použití objektů i v návrhu
informačních systémů. Prvé objektové metodiky bych označil za pilotní, byly to
jen
pokusy použít objektový přístup v návrhu. Příliš se soustředily na objekty a
málo na obecné rysy metodik. V podstatě se vycházelo ze strukturálních postupů,
kde byly datové a funkční modely nahrazeny jediným modelem objektovým.
Objektové metodiky této generace mají velmi zřejmou nevýhodu závisí na tom, jak
člověk mentálně zvládne objektový model. Za této úrovně znalostí se
vytvořil předsudek, že objektový návrh se hodí pouze pro návrh malých systémů.
V celosvětové diskusi v odborné literatuře a na konferencích se objevily
metodiky, které se snaží odstranit tento nedostatek. Jejich množství jde do
desítek. Vytvořily větší množství postupů a jejich členění. Celkově se dají
charakterizovat tak, že metodicky řeší problém, který stál před jejich autory.
Ze zkušeností s těmito metodikami vznikly metodiky 3. generace, které shrnují v
jeden celek jak zkušenosti strukturovaných metodik, tak poznatky o objektech a
zkušenosti s objektovými metodikami. Za metodiky 3. generace lze považovat OOMT
a metodiku k UML.
OOMT (Objektově-Orientované Metodiky a Techniky) vznikly na Vysoké škole
ekonomické v Praze, jejich podstatou je síť nástrojů a postupů, z kterých lze
složit metodiku šitou na míru úloze. Publikováno v roce 1997.
UML (United Modeling Language) vytvořili přední tvůrci objektově-orientovaných
metodik (Booch, Jacobson, Rumbaugh) jako jednotný jazyk objektově-orientovaných
CASE. Publikace metodiky k tomuto jazyku je slíbena na rok 1998.
Probereme si nejdůležitější vlastnosti moderních metodik.
Členění na etapy
Postup vlastní projekce (analýza a design) je důsledněji členěn. Účely
jednotlivých etap jsou následující.
Rozbor zadání: Účelem je porozumět úloze, vytvořit stejný jazyk a stejnou
základnu znalostí pro projektanty, uživatele i zadavatele. Strukturalizovat
okolí a komunikaci s okolím. Výstupem je popis vytvářeného systému jako černé
skřínky.
Analýza: Účelem je popsat logické řešení úlohy, to znamená jen tresť problému,
bez ohledu na prostředí, ve kterém vytvářený systém poběží, bez ohledu na
prostředky, pomocí kterých bude vytvářený systém budován. Výstupem je logický
model, také se říká analytický nebo esenciální model.
Systémový design: Účelem je modifikace logického modelu na designový. Bere se v
úvahu prostředí, ve kterém (a na kterém) systém bude pracovat, určí se
architektura, typ řízení a provedou se další strategická rozhodnutí. Výstupem
je designový model.
Objektový design: Účelem je modifikace designového modelu na implementační.
Zavádějí se redundantní vztahy a data za účelem optimalizace systému, zadají se
konkrétní algoritmy jejich řešení. Výstupem je zadání pro programátory.
Další etapy se obvykle zahrnují pod název implementace. Zahrnují programování
jednotlivých modulů, jejich integraci v jeden celek, testování, ověřovací
provoz a rutinní provoz.
Jednotící role objektů
Podívejme se na obr. 10. Objektový model je společný jazyk celého postupu.
Každá etapa používá speciální dílčí modely (pohledy), jejichž souhrn tvoří
model celého systému. Jako červená nit celým postupem prochází objektový model.
Nejsou zapotřebí žádné převody a překlady, vždy je to model v jedné a téže
řeči, od analýzy po implementaci je to dokonce tentýž model, jen stále
podrobnější a blíže konečnému řešení.
To je obrovská výhoda oproti metodikám, které používají v každé etapě unikátní
pohledové modely a mezi etapami vyžadují převody.
Typy pohledů
Podívejme se na obr. 11. Typy pohledů se ustálily na třech.
Základní pohled je statický (je ekvivalentní objektovému modelu). Popisuje
statické prvky a vztahy. Zavádí objekty, což jsou dělníci systému, vykonávající
všechny činnosti. Vlastně všechny dílčí modely jsou různé pohledy na činnost
objektů.
Funkční pohled popisuje procesní stránku systému, je realizován funkčním
modelem, stejným jako ve strukturovaných metodikách. Popisuje systém jako síť
procesů spojených datovými toky mezi sebou a s datovými sklady. Proces na jedné
úrovni hierarchie se rozkládá na síť procesů nižší úrovně. Popisuje přístupnost
dat pro jednotlivé procesy.
Dynamický pohled popisuje časově závislé činnosti systému. Je k dispozici
několik dynamických modelů, jejich použití závisí na charakteristikách
vytvářeného systému. V podstatě jsou v systémech 2 úrovně dynamiky
meziobjektová a vnitroobjektová.
Meziobjektová dynamika pojednává o impulzech (událostech), které jeden objekt
vysílá druhému, aby příjemce přiměl zahájit nějakou činnost.
Vnitroobjektová dynamika popisuje "paměť" objektů, popisuje to, že chování
objektu závisí na událostech v minulosti. Pracuje se zde se "stavy" a
"přechody" mezi stavy.
Pohledový model popisuje jen určité aspekty vytvářeného systému, jiné aspekty
zanedbává zabývají se jimi jiné pohledy. Z popisovaných aspektů lze vydělit
synchronizační aspekty, to jsou ty, které jsou popisovány ve 2 pohledech a
slouží k prověrce správnosti modelů a k jejich koordinaci.
Synchronizační aspekty jsou velmi důležité z hlediska správnosti projekce.
Jestliže si některé synchronizační aspekty 2 modelů odporují, došlo někde k
chybě, je třeba najít její příčinu a odstranit ji. Není to sice úplná kontrola
správnosti postupu, je to však účinný prostředek. Takovým synchronizačním
prostředkem mezi funkčním a objektovým modelem je to, že datové sklady musí být
adekvátní atributům objektů, nebo že objekty z popisu meziobjektové dynamiky
musí být obsaženy v objektovém modelu. Pohledové modely se nějakou dobu
rozpracovávají paralelně (v etapách analýzy a designu) a pak se vlijí do
objektového modelu.
Pro spojení různých pohledových modelů v jeden objektový model existují
pravidla, jejichž výsledkem je to, že objektový model konzistentně popisuje
vytvářený systém.
V předchozích odstavcích je popisováno současné použití všech 3 pohledových
modelů. Závisí to na charakteru úlohy. Jsou úlohy (např. evidenčního typu), kde
dynamický pohled je tak mizivě využitelný, že jej nemá smysl vůbec zavádět. Na
druhé straně jsou úlohy, kde je klíčovým pohledem funkční model a objektový
slouží jen jako pomocný pohled. Kterýkoli pohled může hrát hlavní úlohu a
kterýkoli pohled může být zanedbán, vesměs však do objektového designu vchází
objektový model (i když byl v analýze použit jako pomocný).
Repertoár modelů
Na obr. 12 jsou uvedeny základní modely, které se v moderních metodikách
používají. Uvedeme si jejich stručné charakteristiky.
V etapě rozboru zadání většina modelů popisuje vytvářený systém jako černou
skřínku, soustředí svou pozornost na komunikaci systému s okolím a na
strukturalizaci okolí.
KD Kontextový diagram popisuje datové toky mezi budoucím systémem a jeho
okolím. Je to vlastně úvodní diagram funkčního modelu.
KOM Kontextový objektový model strukturalizuje okolí budoucího systému a vztahy
z tohoto vyplývající.
POM Pojmový objektový model poněkud se vymyká z této řady modelů, protože
popisuje znalosti o úloze, nikoli úlohu samotnou. Slouží jako objektový zápis
báze znalostí o úloze.
MJ Model jednání (také Use Case) nejdůležitější model této řady, popisuje
scénáře komunikace mezi okolím a vytvářeným systémem černou skřínkou. Model
jednání se vesměs stane součástí zadání a používá se pro kontrolu správnosti
práce ve všech etapách tvorby systému.
Modely analýzy již byly zmíněny výše, trochu doplníme jejich charakteristiky.
FM Funkční model. Doporučuje se jím začít analýzy, protože je hodně intuitivní
a usnadňuje pochopení problému.
OM Objektový model podstatná část této a dalších etap.
DM Dynamický model. Realizace dynamického pohledu se obvykle označuje jako
dynamický model, ve skutečnosti se obvykle jedná o řadu modelů, které se
alternují nebo na sebe navazují. Dynamický pohled má své vlastní etapy a
pravidla, nakonec vyústí ve stavové diagramy pro jednotlivé objekty ovšem jen
pro ty, které mají výrazné dynamické chování. Doporučuje se začít s dynamickým
modelem poněkud později, protože obvykle představuje velký objem práce a je
dobré mít již vyjasněny statické vztahy.
V systémovém designu to již nejsou samostatné modely, ale spíše vzory, podle
kterých se upravuje objektový model na designový. V designu se modifikuje
struktura objektového modelu spíše na úrovni podsystémů než přímo na úrovni
objektů. Činí se zde zásadní rozhodnutí o implementaci.
ARCH Určí se architektura vytvářeného systému. Podle typu úlohy se určí celková
architektura a architektura jednotlivých podsystémů.
ŘÍZENÍ Rozhodne se o použitém typu řízení (procedurální, událostmi, paralelní).
EXTRA Zavedou se zvláštní režimy (spuštění a ukončení systému, pád systému).
TOPO Zvolí se topologie objektového modelu, také s ohledem na výpočetní
prostředí (např. počítačovou síť).
DATA Zvolí se datová reprezentace (soubory, databáze).
KOMPO Rozhodne se, co se bude programovat a co se bude realizovat pomocí
koupených komponent. Upraví se struktura objektového modelu podle požadavků
komponent.
Objektový design vytváří předpis pro programování, podrobně určuje vlastnosti
prvků, metod a vztahů.
ALG Definitivně se zvolí algoritmy (podle požadavků z předchozích etap).
REDUND Provedou se optimalizační úpravy zavádějí se redundantní prvky a vztahy,
odstraní se vícenásobné vztahy (M : N), upravuje se struktura podle
optimalizačních hledisek, tj. rychlost vyhledávání, přístup k údajům apod.
AKTUAL Určí se politika aktualizace hlavně se to týká redundantních prvků.
SD Ze stavových diagramů se vytvoří předpisy pro tvorbu metod (procedur).
STRUKT Z popisu metod se vytvoří jejich programové zadání. U jednodušších metod
popisem vstupu, výstupu a algoritmu, u složitějších metod strukturogramem.
Metodika je cesta sítí prostředků
Proč máme používat metodiku? Co to ta metodika je?
Na tyto otázky vlastně odpovídá celý článek, který právě čtete. Shrneme to do
několika vět:
Metodika je zachycená zkušenost několika generací programátorů a projektantů.
Programátoři a projektanti řeší již půl století své problémy. Své problémy řeší
jak metodou pokusů a omylů, tak i teoreticky. Po
čase jedno (někdy i několik) řešení určitého problému převládne a začne se
považovat za vhodné. Tato vhodná řešení se shromažďují v souhrnech, kterým se
říká "techniky" nebo "metodiky".
Technika je souhrn praxí prověřených předpisů, které jsou jednoznačné,
konkrétní a obvykle se týkají dílčí oblasti.
Metodika je souhrn praxí prověřených doporučení obecného charakteru, která se
týká ucelené oblasti, obvykle vzniku nějakého produktu.
Efektivita projekce je dána volbou vhodné metodiky. Použijeme-li nedostatečnou
metodiku, tj. metodiku, která nepokrývá všechny problémy, pak musíme některé
části řešit "selským" rozumem, jinými slovy metodou pokusů a omylů, tj.
nevyužíváme zkušenosti jiných programátorů a děláme chyby, které již byly
udělány a z nichž si již programátoři vzali ponaučení. Použijeme-li příliš
mohutnou metodiku, děláme zbytečné věci, které nic nepřinesou k řešení našich
problémů.
V předchozí kapitole jsou zmíněny hlavní prostředky a nástroje, které má
projektant k dispozici. Zřídka je však použije všechny. Někdy je absence jejich
použití očividná, jindy je volba prostředků věcí správné taktiky. Volba
prostředků závisí na typu úlohy a také na osobě projektanta.
Lze vytyčit kategorie úloh a formulovat kritéria na jejich vymezení, je to však
poněkud teoretické. Z praktického hlediska považuji za vhodné začít etapu
"Rozbor zadání", speciálně "Model jednání" a "Pojmový objektový model".
Charakter úlohy se většinou ukáže. Dále doporučuji začít funkčním a objektovým
modelem (odložit dynamický model). Charakter úlohy se brzy projeví. Tento
postup je popsán na obr. 12. U některých úloh je jejich charakter předem dán,
např. u úloh s reálným časem a u úloh typu BPR (Business Process Reengineering)
je zřejmé, že to jsou úlohy dynamického charakteru. Vhodný postup pro takové
úlohy je na obr. 13, kde vidíme, že se nejdříve pracuje s dynamickým modelem a
teprve z něj se odvozuje objektový model.
Boj proti složitosti
Boj se složitostí je základní náplní činnosti projektantů. Tvorba složitějších
informačních systémů má tu nepříjemnou vlastnost, že chyby v libovolné etapě se
často odhalí až v etapě zkušebního provozu, a to může trvat dost dlouho. Chyby
nelze zjistit, protože systém neběží, pořád jsou to jen nákresy na papíře. Jsou
samozřejmě vyvinuty postupy, které mají tuto nepříjemnost zmírnit (vnější a
strukturovaná oponentura) to je věcí organizace procesu projekce, za klíčovou
však považuji sebekontrolu projektanta.
Lze rozlišit pouze tyto druhy obecných principů pro boj proti složitosti:
lrozklad (hierarchický rozklad) a jeho protiva skládání celku z konkrétních
jednotlivostí,
labstrakce a její protiva specializace,
literace (opakování).
Rozklad je základní zbraní projektantů a využívá se v různých formách. Jedná se
vlastně o vztah celek část. Pro popis tohoto vztahu se v jednom směru používá
slovo "rozklad", obvykle ve spojení "hierarchický rozklad", ve druhém směru se
používá "integrace", "agregace", "seskupení".
Vztah skupina část můžeme rozlišovat na prostý a synergický. Prosté seskupení
je takové, že skupina má jen součet vlastností, které mají její členové.
Synergické seskupení je takové, že skupina má navíc vlastnosti, které její
členové nemají; obvykle se označuje slovem "integrace" nebo "agregace".
Příkladem může být rozdíl mezi davem (prosté seskupení) a plukem (synergie).
Rozlišení druhů seskupení na synergické a prosté je v objektově-orientovaném
návrhu velmi důležité. Na mnohých místech se synergická seskupení používají a
projektantovi musí být jasné, jak tuto synergii realizovat. Například objekt je
synergické seskupení funkcí a dat, nebo metody a atributy kontejneru jsou
realizací synergických vlastností skupiny objektů, které kontejner obsahuje.
Proces abstrakce se vždy popisuje jako zanedbání nepodstatných vlastností a
souvislostí, takže abstrahovaná entita je vždy jednodušší (menší rozsahem i
obsahem) než původní. Je účelné rozlišovat dva druhy abstrakce:
labstrakce jednotlivin,
labstrakce skupin.
U abstrakce jednotlivin vydělím třídu určitých entit a odvrhnu ty vlastnosti
entit, kterými se navzájem liší. Zbylé vlastnosti jsou vlastnosti abstraktní
entity této třídy. Například pojem "člověk" je abstrakcí lidských bytostí. Jiný
příklad, nadtřída (objektová) je abstrakcí svých podtříd.
Pro abstrakci jednotlivin se obvykle používají slova "generalizace" a
"specializace", ale také "abstrakce" v užším smyslu, nebo "redukce" s
doplňujícím významem, že konkrétnější entita nemá všechny vlastnosti abstraktní
entity. Pro vztah mezi třídou a objektem se používá slovo "instanciace" (objekt
je instancí třídy).
Abstrakce skupin je trochu jiný proces. Vezmeme nějak vydělenou skupinu entit,
které jsou navzájem spojeny nějakými vztahy. Odvrhneme tyto vzájemné vztahy,
abstraktní entita si ponechává jen ty vlastnosti a vztahy, kterými se původní
skupina entit projevuje ke svému okolí. Například (školní) třída je skupinová
abstrakce žáků. Příklady z projekce: kontejner obsahuje jiné objekty (objektový
model), proces je tvořen jako souhrn svých podprocesů pojmu rozhodovat, zdali
to, s čím jsem se setkal, je nebo není člověk.
Výše uvedené odstavce jsou poněkud teoretické, o tom není spor









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