2. Rýchle prototypovanie
2.1 Všeobecný model spätnej väzby
2.1.1 Viacnásobný výkyt modelov
2.2 Špirálový model
2.3 Entitno relačné modely
2.4 Objektové modelovacie techniky
2.5 Systém LOCANA
2.6 Mapovanie špirálového modelu na návrhové schémy
2.7 Špirálové rameno životného cyklu softwérového vývoja
2.8 Degenerácia životného cyklu
2.9 Aplikácia metafory
2.9.1 Zdôvodnenie predradenia
2.9.2 Zavedenie predradenia
2.10 Problémy, ktoré musia byť adresované

V súčasnej dobe je veľká pravdepodobnosť nedostatočnej komunikácie medzi objednávateľom a dodávateľom softwarového systému. Medzi najčastejšie dodávané systémy patria : 

• Počítačové systémy
• Softwarové systémy
• Aplikačné systémy
• Informačné systémy
• Zbrojné systémy
• Medicínske systémy

• automaty
• boolovske funkcie
• algebraické špecifikácie
• Petriho siete
• procesné algebry

Z dôvodu eliminácie chýb sa vytvárajú prototypy, ktoré čiastočne simulujú vlastnosti požadovaného systému ale nespĺňajú všetky požiadavky. Táto práca sa zaoberá rýchlym prototypovaním, teda tvorbou prototypov, ktorými sa predchádza nevhodným modelom a zabezpečuje sa redukcia cien softwaru. 

Slovo “prototypovanie” má niekoľko významov a je dosť náročné nájsť ten, ktorý by vystihoval podstatu. Tento problém je čiste sémantický. Niektoré z definícií sú v čiastočnom rozpore s ostatnými. Napríklad Shang (SHANG96) definuje prototypovanie ako “iteračné priblíženie podmienkam analýzy vytváraním funkčných 

foriem systému.” Prototyp, ktorý takto vzniká je pracovný model informačného systému, ktorý dáva dôraz na vzhľad systému a poskytuje komunikačné nástroje pre zákazníka a vývojára, zabezpečuje komunikáciu. Dochádza teda k získavaniu ďalšich poznatkov pre zdokonalenie finálneho produktu, prototyp sa ďalej hodnotí a zdôrazňujú sa rozdiely medzi nim a finálnym produktom.Pojem iterácie spomenutý v definíci prototypovania znamená budovanie postupných verzií, ktoré sú funkčné. Je dôležité, že nie je možné začať novú iteráciu, pokiaľ predechádzajúca nie je plne ukončená. Existujú aj ďalšie definície, ktoré sa však rozchádzajú. 

1.2.1 Delenie throwaway and development

1.2.2 Delenie podľa účelu

• Mock-Up- prototyp dáva uživateľovi náhľad ako to asi bude vyzerať
• Bread-Board- prototyp beží ale ešte nemá vyvinuté užívateľské rozhranie
• Scale Model- beží,má užívateľské rozhranie ale podporuje iba časť všetkých podmienok
• Concept-Car- kde prototyp je vyvinutý za účelom zistenia trhovej ceny
• Simulácia- kde prototyp extrahuje scenáre a predstavy užívateľa
• Charakteristický model- formálna špecifikácia systému
• Blue-Print- popis ako urobiť reálnu implementáciu systému 
• vykonateľný Blue-Print - popis ako urobiť reálnu implementáciu, ktorá je tiež simuláciou výstupov 

• 1.2.3 Ortogonálne a diagonálne prototypovanie

• horizontálne 
• vertikálne

Prototypovanie nie je to isté ako rýchly vývoj aplikácií t.j. Rapid Application Development (RAD). RAD je prístup ktorý sa usiluje doručiť kompletný systém tak rýchlo ako je to len možné. Produkty RAD sú nepoužiteľné a procesy nie sú povinne iteračné alebo rekurzívne. Toto je v kontraste s rapídnym prototypovaním kde produkty viac vyhovujú požiadavkám systému. Prototypovanie môže byť použité ako časť RAD stratégie. 

Softwerové ceny často prevyšujú predpokladané hodnoty kvôli prerábaniu už urobenej aplikácie, keď sa z nejakých dôvodov robia zmeny vzniknuté chybami komunikácie. Chyby urobené vo fáze definovania požiadaviek sa stávajú stále viac nákladnými keď sa opravujú. Projekt, ktorý vyhovuje požiadavkám je podľa definície úspešný. Na druhej strane, niektoré nevyhnutnosti nie je možné identifikovať pokiaľ systém už nie je hotový. Proces vymedzenia požiadaviek užívateľa pre softwérový systém je často napadnutý nerozhodnosťou, nejednoznačnosťou, nezrovnalosťou. Tu môže nastať situácia, že projekt, ktorý je inak po formálnej stránke, čo sa týka kódu dobrý, môže prekročiť finančný rozpočet ale nie kvôli slabým programátorským zručnostiam ale preto, že analyzovanie požiadaviek neukázalo zamýšľané vlastnosti systému.

V súčasnom prieskume 85% zdrojov uviedlo, že použitie rapídneho prototypovania sa 

osvedčilo v zlepšení kvality softwéru. Napríklad:

• Pomáha zaručiť, že podstata systému bude správna
• Poskytuje nahliadnutie do alternatív navrhnutých prístupov
• Údržba stojí menej odkedy sa predpokladá, že užívateľské potreby sú lepšie plnené
• Vyvíjacie úsilie je redukované

Na rýchle prototypovanie je možné sa pozerať ako na postupnosť iterácii, t.j. vytváranie čiastočne funkčných modelov systému. Prechod na ďalšiu iteráciu nemôže byť uskutočnený kým tá predošla nie je ukončená.Nasledujúca schéma popisuje jednu iteráciu prototypovania a zároveň vysvetľuje sľučku. Na začiatku vývoja je potrebné stanoviť spôsob kontroly spravnosti produktu a vytvoriť bázu modelov, ktorá sa bude počas nasledujúcich iterácii ďalej meniť. Na základe bázy modulov a stanoveného spôsobu kontroly produktom softwarového vývoja je nejaký výstup. Tento produkt však nespĺňa všetky podmienky a je vstupom v ďalšej iterácii.

Vysvetlivky 

C = n-tica označujúca všetky možné konštrukcie modelov dostupných v jednej iterácii

L = množina konštrukcie modelov naviazaných naspäť na proces t.j. presne tie modely, ktoré sa v danej iterácii použili; potenčná množina množiny C

f(L) = funkcia, ktorá na základe všetkých modelov použitých v danej iterácii rozhodne, ktoré z nich sa menia v novej iterácii t.j. L´ = f(L) a zároveň sa vyhodnocuje predikát, ktorý rozhoduje o tom či má nastať ďalšia iterácia. Ak platí :

$ c : C | c Î L_f L c ? L’

potom už ďalšia iterácia nenasleduje.

L´ = množina modelov po modifikácii procesom, t.j. tie modely, ktoré sa v danej iteracii menia ; potenčná množina množiny C

L_f = množina takých modelov, ktoré sa získajú v poslednej iterácii; potenčná množina množiny C

2.1.1 Viacnásobný výkyt modelov

V roku 1986 Böhm navrhol model špirálového životného cyklu, tým potvrdzujúc nelineárnosť činností softwérového inžinierstva. Tento špirálový pohľad sa stal populárny medzi navrhovateľmi evolučného prototypovania, pretože poskytuje prostriedok, pomocou ktorého môžu byť projekty prírastkovo vyvíjané (budujúc na predchádzajúcich skúsenostiach) s použitím toho istého základu.

Špirálový model môže byť ilustrovaný stabilnejšie v nasledujúcej schéme.

t = jednotka času
T = celkový čas vývoja tak, že t je veľmi malá časť T. 

Ak iniciačná úroveň vývoja systému má základňu AB a má danú magnitúdu 1, ortogonálne použitie programu v časovom intervale t=1 spôsobí zmenu základne, reprezentovanej vektorom magnitúdy 2. Opakovanie tejto procedúry bude mať ako výsledok sériu pravouhlých trojuholníkov opisujúcich logaritmickú špirálu. Táto schéma sa zhoduje s geometrickou slučkou spätnej väzby

Každý trojuholník závisí na spätnej väzbe svojho predchodcu (prepona sa spätne naväzuje do procesu a stáva sa základňou ďalšieho). Je vidieť, že predĺženie každej iterácie, ktoré je charakteristické časovou premennou t prináša zväčšenie obsahu trojuholníka, ktorý je zhodný s cenou danej iterácie.

Entitno relačný model predstavuje sémantické dátove objekty vysvetľujúce notáciu abstraktných objektov a vzťahov medzi nimi. Platí : 

• entita je abstraktný pojem pozostávajúci s atribútov a vzájomných vzťahov medzi nimi.
• je podporovaná kompozícia atribútov
• medzi základné primitíva patri :

2.4 Objektové modelovacie techniky

Medzi základné prvky objektových modelovacích techník patria :

• trieda (class) : zložená z názvu, atribútov a metód
• dedenie (generalisation) : dochádza k prenášaniu vlastností tzv “super” triedy na podtriedy
• spojenie (aggregation)
• asociácie (asociations) : práve jeden, viac než jeden, buď jeden alebo žiaden, numerická špecifikácia, asociácia ako trieda.
• inštancia

V súčasnej dobe sa urobil veľký pokrok v oblasti CASE nástrojov. Jedným z programov na tvorby prototypov je systém LOCANA, ktorý využivá niektoré zo základných požiadaviek na systém pre rýchle prototypovanie. Tieto požiadavky sú :

V špirálovom pohľade na vývojový proces sú softwérové modely zjemnené iteráciami L´=f(L). Z tohto pohľadu sa návrhové schémy môžu pridať počas ktorejkoľvek iterácie, takže sa môže vracať rekurzívne v ktoromkoľvek úseku vývojového procesu a na premenlivej úrovni detailov modelu. Samozrejme to neznamená, že tie isté schémy sa vždy objavia na danej úrovni iterácie. Napríklad – keď skúmame horné dve úrovne hierarchie (alebo JSD diagramu), vzorka sa nemusí opakovať na úrovniach dva a tri, tri a štyri, atď. V skutočnosti sa vzorka veľmi pravdepodobne nezopakuje týmto spôsobom. Prečo? 

Situácia vyzerá nasledovne: model vstúpil na úroveň zložitosti úplne inej než je tá, ktorú opisuje logaritmická špirála vo vývoji životného cyklu, kde sú všetky intervaly iterácie navzájom podobné a pripomínajú vždy predchádzajúci interval. Model životného cyklu je možné opísať použitím Pytagorovej metafory (čo je jednoduchá ekonomická matica spolupráce a riadenia), pretože neboli dané žiadne obmedzenia na spôsob riadenia projektu. Takáto voľnosť nie je možná v softwérových modeloch, pretože tieto samy určujú vnútornú zložitosť aplikačných polí skutočného sveta.

V skutočnosti je úloha spätnej väzby v aplikačnom poli len funkciou úlohy spätnej väzby v korešpondujúcom poli problému. Ako taká je sama sebe veľmi podobná, má aj možnosť “samopridruženia” (takže určité schémy softwéru sa príležitostne objavia znovu). Slučka spätnej väzby je oveľa komplexnejšia a zložitejšia ako povoľuje Pytagorova metafora. 

Toto je dôvod, prečo sa návrhové schémy opakovane používajú bez potreby takých metafor. Je oveľa praktickejšie identifikovať bežne používané abstrakcie a vtedy, keď nastanú ich použiť na základe princípu ad-hoc.

Problém je ďalej komplikovaný Rumbaughovými dimenziami iterácie, keďže abstrahovanie, ktoré si zvolíme použiť na ktorejkoľvek úrovni iterácie, môže závisieť na parametri, cez ktorý iterujeme – napr. ak iterujeme po šírke a nie po hĺbke, nemusíme rozpoznať tie isté štruktúry.

Ako potom môže byť špirálový životný cyklus rozvrhnutý do komplexných softwérových modelov, ktoré má vytvárať? K tomu, aby sme našli riešenie, musíme sa vrátiť k špirálovému životnému cyklu spomenutému vyššie, ktorý modeloval proces softwérového projektovania, a nie konkrétnych produktov. Môžeme proces zjemniť tak, aby bral do úvahy dimenzie iterácie a to nám dá všeobecné riešenie - model spätnej väzby, na ktorý môžeme rozvrhnúť softwérové schémy na obvyklom ad-hoc princípe.
 

V ďalšom kroku vezmeme geometrickú slučku a vyjadríme ju trochu iným spôsobom (viď schéma 2.4):

Urobili sme nasledovné zmeny:

(1) Druhá mocnina každej strany každého trojuholníka na obrázku predstavuje veľkosť investície do projektu. Každý krok je súhrnom výkonu vynaloženého v predchádzajúcich úsekoch progresie a zjemňovania (predstavovaná druhými mocninami pri ostatných dvoch stranách trojuholníka).

(2) Vývojové úsilie nie je použité len na to, aby posunul projekt do ďalšej fázy životného cyklu, ale aby umožnil vykonávanie ďalších zjemnení na súčasnej úrovni.

(3) V rámci splnenia Pytagorovej vety čas investovaný do presunutia z jednej fázy do druhej nemôžeme považovať za jednotný, pretože nejaký čas musíme investovať aj

do zavedenia ďalších úprav abstrahovania na súčasnej úrovni.

Toto sa prejaví v modele životného cyklu a výsledok je zobrazený v schéme 2.5.

Model životného cyklu je zjavne stále špirálový, ale rysujú sa ďalšie ”dcérske” špirály, ktoré sa rozvetvujú a môžu byť ďalej zjemnené počas nasledujúcich iterácií. Každá dcérska špirála absorbuje určitú časť vývojového úsilia vynaloženého počas danej iterácie a postupne sa zvyšujúca zložitosť modelu má za následok predĺženie času na dokončenie ďalších iterácií, keďže sa k produktom životného cyklu pridávajú stále nové a nové súčasti. 

Technicky každá dcérska špirála predstavuje kontrolu a ďalšie zjemnenie tých konštrukcií, ktoré boli abstrahované na predchádzajúcej úrovni. Takže ak napríklad bola iterácia vedená spôsobom zhora-nadol, prvá dcérska špirála môže reprezentovať prídavok k všeobecnej rodičovskej triede a nasledovné iterácie pridajú konštrukcii viac súčastí, ako podtriedy. Naopak, stratégia zdola-nahor môže vyústiť v abstrahovanie niektorých špecializovaných tried na začiatku a následné začlenenie ich realizácie do rodičovských tried v ďalších iteráciách. 

Upravený špirálový model ukazuje vysoký stupeň “samopridruženia” – každá dcérska špirála vyzerá ako miniatúrny vír celého vývojového procesu. Znamená to, že každý objekt ukazuje a sleduje vlastný životný cyklus svojho vývoja, aj keď všetky spolupracujú, aby sformovali vývojový proces v jeho celosti. 

Ďalšie zjemnenia môžu viesť k vytvoreniu nových objektov, každý opäť načrtáva svoj vlastný príklad životného cyklu, ktorý sa môže stať predmetom ďalších zjemnení, vytvárajúcich nové vývojové procesy, atď. Pokiaľ sú prepojenia medzi modulmi kompletne definované, vnútorné zložky môžu byť vyvíjané nezávisle a nie je nevyhnutné vyvíjať každý modul do detailu predtým, než začne kódovanie. Špirálový model vo veľkom je zameniteľný s makroprocesom opísaným Boochom. Obrátene, dcérske špirály reprezentujú mikroprocesy. Upravený špirálový proces ukazuje relatívnosť pojmov ”makro” a ”mikro” – vývojový životný proces podschémy môže byť ”mikroproces” vo vzťahu k ”makroprocesu” celého projektu, a zároveň ”makroproces” vo vzťahu k ”mikroprocesom” svojich vlastných členov. Výsledkom je ”degeneratívny” model životného cyklu, ktorý vybavuje každý produkt jeho vlastnou vývojovou cestou, ale ktorý súčasne dovoľuje systému vyvíjať sa v ”evolučnom” štýle. Táto dualita degenerácie a evolúcie reprezentuje mapu pre vyvíjanie softwéru nasledujúcich generácií. Návod sa skrýva v porozumení schémy spätnej väzby. 

Jedno možné riešenie problému prispôsobovania procesu prototypovania je vybudovať integrovanú objektovo orientovanú metodológiu od samého začiatku, napr. kompletný model životného cyklu, ktorý bol špeciálne skonštruovaný, aby zahŕňal rozvinutú fázu RFP. V tejto práci je opísaný proces pre RFP, ktorý je predradený zavedeným objektovo orientovaným metodológiám. Výsledky tejto prekurzívnej etapy sú potom spracované do analýzy a návrhových etáp cieľovej metodológie. Ak tá podporuje CASE, potom sa môže realizovať prepojenie s RFP fázou s použitím DDL konvertorov alebo bežnými zdrojmi s primeranými prostriedkami na ovládanie nastavenia.
 

• 2.9.1 Zdôvodnenie predradenia

Fáza prototypovania podľa Vonka môže byť považovaná za ”miniatúrny životný cyklus”, ktorý spĺňa fázu definovania požiadaviek vo väčšom, tradičnom lineárnom procese (viď schéma 2.6.1a). Connel a Shafer tiež identifikujú veľa podobností medzi životným cyklom prototypovania a bežným vývojom, hoci model prototypovania, ktorý ponúkajú, pokrýva rovno životný cyklus kompletných systémov. Gomaa zaviedol podobný upravený životný cyklus, ktorý odráža vplyv prototypovania. Zatiaľ čo autorove skúmanie podporuje predpoklad, že proces prototypovania skutočne má veľa spoločných vlastností so všeobecným vývojovým životným cyklom, navrhované riešenie nevyžaduje zahrnutie do väčšieho modelu alebo nahradenie bežných modelov životného cyklu v celku ani po častiach.

1.Predbežná analýza a špecifikácia užívateľských požiadaviek 
2.Návrh a implementácia prototypu 
3.Skúšanie prototypu 
4.Iteračné zjemňovanie prototypu 
5.Úpravy špecifikácie požiadaviek 
6.Návrh a implementáca výrobných systémov

Vonkov prístup, aj keď je založený na súvislej teoretickej báze, môže byť kritizovaný z praktických dôvodov – neexistuje záruka, že vybraná metodológia môže vyhovovať prototypovaciemu miniprocesu. Inými slovami, nemôžeme sa zaoberať životným cyklom vývoja softwéru iba ako s abstrakciou; skutočný svet softwérového inžinierstva zahŕňa špecifické metodológie, ktoré sú definované určitými spôsobmi a s určitými obmedzeniami. Ak má byť prototypovací proces podporený zvnútra, musí sa zjednotiť s vybranou metodológiou v pojmoch nástrojovej podpory, činiteľov ako modely, dokumentácia, matrice sledovateľnosti, kontrola verzie a rozdelenie ľudských zdrojov. 

V podstate zavedené objektovo orientované metodológie neposkytujú prepojenie s prijatím definovanej prototypovacej fázy. Aj keď neprítomnosť špecifikovaných vstupných podmienok na integráciu modelu RFP procesu znamená, že v skutočnosti netreba vyradiť nič alebo len veľmi málo, vývojový pracovník musí stále čeliť problému, ako zmapovať jednotlivé vstupy a výstupy procesov navzájom. Veľmi pravdepodobne sa potom objavia ad-hoc prístupy, ktoré zavádzajú čiastočné mapovacie funkcie medzi fázou prototypovania a metodológiou.

Argument proti Gomaaovi, Connelovi a Shaferovi je pragmatický. Rýchle prototypovanie nemôže realisticky dúfať, že nahradí zaužívané metodológie životného cyklu, kvôli jemnému prevládaniu každej metódy v organizačnej kultúre. Osvojenie si novej metodológie vyžaduje značné výdavky, napr. na reštandarizáciu organizácie okolo nového modelu životného cyklu a súbor podporných nástrojov, rekonfiguráciu existujúcich dokumentačných štandardov a rekvalifikáciu pracovníkov. Táto zmena môže zabrať viac ako rok a nemusí byť ekonomicky realizovateľná pre veľa projektov.
 

• 2.9.2 Zavedenie predradenia

Kým tu uvedené riešenie si zachováva veľkú časť rovnakej základnej štruktúry ako modely prototypovania navrhnuté Vonkom, Gomaaom, Connelom a Shaferom, nie je vložené do žiadnej metodológie, ani používané ako náhrada. Namiesto toho je cieľová metodológia predradená procesom RFP. Teda produkty prototypovacej fázy sú dostupné vývojovým pracovníkom, ktorí sledujú cieľovú metodológiu ako základné prvky problémovej sféry. Môžu byť začlenené do štyroch kategórií:

• objektovo orientované modely, ktoré môžu byť znovu použité v metodológii s podporou CASE (napr. importovaním z bežných zdrojov a použitím pravidiel metodológie a jej súboru podporných nástrojov z dôvodu ich prevedenia do realizovateľného analytického modelu danej metodológie).
• objektovo orientované modely, ktoré môžu byť znovu použité v metodológii bez CASE podpory (tento spôsob podporujú Coad a Yourdon, ktorí podporujú opakované použitie staršieho materiálu z iných systémov pre podobné a totožné oblasti problémov).
• Špecifikácie, tak formálne ako vykonateľné, na ktoré sa môžeme odvolávať počas vývojového životného cyklu.
• Dokumentácia vyjadrujúca inak nehmotné skúsenosti získané v oblasti prototypovania (môže to zahŕňať tiež odporúčania, ktoré metodológia najviac vyhovuje vývoju systému).

V tejto práci je zobrazený ekonomický, CASE podporovaný prístup k rýchlemu prototypovaniu kvôli zisťovaniu podmienok. Tento prístup je dosť flexibilný na efektívne vytvorenie univerzálneho pracovného prostredia pre rýchle prototypovanie. Avšak práve flexibilita prístupu prináša nielen osoh, ale aj nástrahy. 

Hlavný problém leží vo výrobe vykonávateľných špecifikácií (modrotlačové vykonateľné programy) a export modelov. Gordon naznačuje, že jedna z nástrah ”neopraviteľného” prototypovania je, že takýto prototyp nebude odložený, ale že sa môže vyskytnúť tendencia pokúsiť sa ”vtlačiť” ho do implementácie. Je tu tiež nebezpečenstvo, že ak koneční užívatelia dostanú príliš voľný prístup k prototypu, môžu rozpoznať práve jeho nekompletnosť a zlú schému.

Pozrime sa na vec z pohľadu, akým sa pozerá softwérové inžinierstvo, podobne ako väčšina ostatných inžinierskych oblastí, na disponibilné súpravy nástrojov, ktoré musia byť zodpovedne používané, na účely, na ktoré sú zamýšľané. Prototypovacie nástroje sa používajú na konštrukciu prototypov, a ak je export modelov do formálneho vývoja podporovaný tiež, potom by to malo byť považované za funkciu, ktorú môže šikovný inžinier využiť ako výhodu. Nemalo by to byť kritizované iba kvôli možnosti zneužitia alebo chybného využitia, a tiež by malo byť objasnené užívateľovi, že prototyp je prípadne použiteľný ako testovacia verzia.

Objektová orientácia podporuje použitie uzavretých abstrakcií s jasne definovanými dohodami. Implementácia tried môže preto byť vyvinutá v izolácii od projektovania rozhraní, ktoré predstavujú pre klienta. V takejto izolácii môžu vývojové procesy sledovať oddelené vývinové cesty. Objektová orientácia ako taká sa prepožičiava nelineárnemu vývojovému životnému cyklu. Pokusy o separáciu týchto nelineárnych stratégií do iteračných a rekurzívnych modelov sú značne umelé a v tejto práci sme vám ponúkli alternatívnu spätnú väzbu založenú na metafore. Ukázali sme, že táto metafora je vhodnejšia pre modelovanie vývojových životných cyklov a načrtli sme koncepciu aplikácie výhod nelineárneho vývoja použitím štruktúry rýchleho prototypovania.