Proces návrhu softvéru
Proces tvorby softvéru začína od hrubého návrhu a končí hotovým kódom.
V nasledujúcom texte bude ukázané, ako sa dostať z bodu A do bodu B v najkratšom čase. Bod A môžeme charakterizovať nasledovne: "Mám predstavu o tom, čo môj systém má čo robiť. Mám premyslené určité prípady použitia". Bod B predstavuje skompletovaný a otestovaný kód, ktorý robí to, čo je špecifikované v prípadoch použitia na začiatku. Inými slovami, kód implementuje požadované správanie, ako je definované pomocou prípadov použitia. Ukážeme ako sa môžeme dostať zo stavu "Myslím, že chcem, aby to robilo niečo také" do stavu, keď budú tieto popisy jednoznačné, úplné a striktné, takže si môžete vytvoriť dobrú architektúru softvéru a následné čistý kód, ktorý implementuje navrhnuté správanie.
Pri návrhu softvéru budeme pracovať pospiatky - od kódu, a vysvetlíme, kroky vedúce k nášmu cieľu. Na nasledujúcom obrázok sú dva predpoklady. Predpokladáme že:
- sme urobili niekoľko prototypov, ktoré nám dajú určitú predstavu o tom, ako naše používateľské rozhranie bude vyzerať, a
- máme určité scenáre alebo prípady použitia o našom systéme
Na začiatku celého procesu máme určité (a možno neurčité) predstavy o budúcom systéme. V nasledujúcich krokoch teba vyplniť oblasť, ktorá je na obrázku naznačená otáznikom.
V objektovo orientovanom prístupe je štruktúra nášho kódu definovaná v triedach (pozri Java - objektovo orientovaný prístup). Predtým, ako začneme písať kód, chceli by sme vedieť, aké triedy bude náš kód obsahovať. K tomu potrebujeme jeden alebo viaceré diagramy tried, ktoré ukazujú triedy a ich vzájomnú súvislosť v navrhovanom systéme. Každej z z týchto tried je potrebné definovať kompletnú sadu atribútov, čo sú vlastne vlastnosti danej triedy a operácie, ktoré definujú funkcie softvéru. Inými slovami, musíme identifikovať všetky funkcie softvéru.
Ukážeme ako sú v triedach zapúzdrené dáta a metódy a aká je navrhnutá hierarchia tried. Pre reprezentáciu týchto informácií použijeme diagram tried (Class Diagram). Výsledkom návrhu tried je podrobná špecifikácia tried na úrovni implementácie. Táto úroveň predstavuje akúsi šablónu pri písaní samotného kódu.
Na nasledujúcom obrázku je naznačené, že diagramy tried sú krok pred samotným kódovaním. Tieto triedy sú navrhnuté na úrovni implementácie. Táto úroveň dáva návod ako vytvoriť triedy v samotnom kóde. Existuje tu mapovanie 1:1 medzi triedami v diagramoch tried a triedami v samotnom kóde.
Stále tu máme istú medzeru, pri komplexnom návrhu softvéru. Teraz musíme vyplniť túto medzeru medzi prípadmi použitia a diagramami tried.
Jedna z najťažších vecí, ktoré sa musia pri objektovo orientovanom vývoji softvéru urobiť, je návrh správania sa softvéru. V tejto časti robíme návrh správania sa keždej časti softvéru. Pre každú funkcionalitu softvéru je potrebné rozhodnúť, ktorá trieda bude toto správanie implementovať. Je potrebné definovať správanie sa každej časti softvéru.
Jeden z UML diagramov, ktorý je vhodný pre tento opis je sekvenčný diagram. Tento diagram je ideálnym prostriedkom, ktorý nám pomôže tieto opísať správanie sa softvéru, resp. jeho jednotlivých častí. Sekvenčné diagramy sú vytvárané pre jednotlivé scenáre, resp. pre každý scenár. Sekvenčný diagram ukazuje ako komunikuje objekt (inštancia triedy) s ostatnými objektami pomocou mechanizmu predávania správ.
Nasledujúci obrázok ukazuje, že prázdne miesto medzi prípadmi použitia a kódomm je síce menšia, stále tu existuje prázdne miesto. Teraz sa musíme dostať od prípadov použitia k sekvenčným diagramom.
O tom, ako sa bude náš softvér správať, hovorí sekvenčný diagram. Pomocou akcií v sekvenčnom diagrame môžeme definovať v diagrame tried jednotlivé metódy tried. Úlohou je teraz dostať sa z prípadov použitia do sekvenčných diagramov. Toto je vo väčšine prípadov netriviálny problém, pretože prípady použitia definujú úroveň požiadaviek na softvér a sekvenčný diagram definuje veľmi podrobný pohľad na návrh softvéru.
Kľúčovou vlastnosťou procesu ICONIX je definovať práve tento skok. Od "Čo" k "Ako".
Teraz je potrebné preklenúť medzeru medzi neurčitým definovaním prípadov použitia k veľmi podrobným a presným sekvenčný diagramom. Toto prepojenie nám pomôže zládnuť ďalší typ diagramu: diagram robustnosti. Na nasledujúcom obrázku ukazuje je pridaný ďalší diagram - diagram robustnosti. Diagram robustnosti nám pomôže vyhnúť sa bežným problémom v projektových tímoch.
