Proces návrhu softvéru
| Naspäť na | Softvérové inžinierstvo |
Proces tvorby softvéru začína od hrubého návrhu a končí hotovým kódom.
Obsah
Princíp procesu ICONIX
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 zvlá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.
Analýza robustnosti vypĺňa medzeru medzi tým, čo má systém robiť, a ako to bude implementovať. Ako prvé, pri tejto analýze, snažíme sa objaviť objekty, na ktoré sme pri prvom odhade štruktúry softvéru. Taktiež môžme do existujúcich tried pridať chýbajúce atribúty. Ďalším nemenej dôležitým krokom je podľa potreby aktualizovať texty v Use Case diagrame.
Ďalším diagramom, ktorý budeme opisovať je doménový model, ktorý je akýmsi náčrtom funkcionality navrhovaného softvéru. Inak povedané, pre tvorby tohoto diagramu použijeme podstatné mená, ktoré navrhovaný softvér charakterizujú. Ak bude náš softvér pracovať s elektronickým obchodom, tak doménovými objektami budú katalóg, objednávka, artikel, ... . Tieto podstatné mená, ktoré charakterizujú softvér budeme nazývať doménové objekty a pomocou týchto doménových objektov načrtneme doménový model, ktorý bude základom pre diagram tried. Doménový model je základom pre diagram tried. V doménovom modeli sa neuvádzajú atribúty ani členské metódy.
Na nasledujúcom obrázku je proces návrhu spftvéru skoro dokončený. Medzera medzi stavom A a B je už vyplnená UML diagramami.
Pre prechod od stavu A do stavu B sme použili 4 rôzne UML diagramy:
- diagram prípadov použitia,
- diagram analýzy robustnosti,
- sekvenčný diagram,
- doménový model a diagram tried.
Doménový model vytvára model na úrovni analýzy softvéru. Tento model opisuje softvér zo statického hľadiska, teda z jeho štruktúry. Keď máme prvý návrh doménového modelu, začneme pracovať na vytváraní prípadov použitia. Tieto prípady použitia opakovane prechádzame a dopĺňame detaily. Nájdené nedostatky, resp. vylepšenia zároveň dopĺňame aj do diagramu tried. Po vytvorení všetkých scenárov, ktoré by mal softvér podporovať (resp. implementovať)
Na nasledujúcom obrázku je znázornený rozdelenie procesov návrhu softvéru v procese ICONIX. Na obrázku sú 2 časti: vrchná časť reprezentuje dynamický model, ktorý opisuje správanie sa softvéru a v spodnej časti je statický model, ktorý opisuje štruktúru softvéru.
Pri návrhu sofrvéru môžeme začať s návrhom prototypov, alebo si jednoducho nakreslíme obrazovky softvéru. Z týchto náčrtov vytvoríme prípady použitia softvéru. Do scenárov doplníme opisný text. Počas analýzy robustnosti môžeme jednotlivé prípady použitia upravovať. Tvorbu sekvenčného diagramu začíname až po dokončení prípadov použitia.
Vlastnosti procesu ICONIX
Pred samotným návrhom systému je potrebné vedieť odpovedať na nasledujúce otázky:
- Kto sú používatelia systému a čo sa snažia v systéme robiť?
- Aké objekty sú potrebné pri konkrétnom prípade použitia?
- Ako interagujú objekty medzi sebou v prípadoch použitia?
- Ako budeme v reálnom čase spracovávať údaje v systéme?
- Ako budeme v skutočnosti realizovať systém na najnižšej úrovni?
Proces návrhu softvéru je určitý plán, ktorý musí vývojový tým nasledovať. Tento plán zahŕňa časové úseky, ktoré sú označované ako míľniky.
Proces ICONIX v skratke
V samotnom procese ICONIX existujú 4 míľniky:
Míľnik 1: Prehľad požiadaviek
- Indetifikácia objektov v systéme, generalizácia a agregácia vzájomných vzťahov medzi objektami. Tvorba doménového modelu.
- Ak je to možné, vytvoriť jednoduchý prototyp grafického používateľského rozhrania systému.
- Indentifikácia prípadov použitia.
- Rozdelenie prípadov použitia do skupín. Z diagramov použitia vytvoriť jednotlivé balíčky (kategórie).
- Identifikovať funkčné požiadavky na prípady použitia a doménové objekty.
Míľnik 2: Analýza a predbežný návrh
- Vytvoriť podrobný opis prípadov použitia
- Vykonať analýzu robustnosti. Pre každý prípad použitia:
- Analyzovať objekty v dano prípade použitia
- Upraviť doménový model novými objektami a atribútmi získanými z predchádzajúceho bodu.
- Finalizovať diagram tried.
Míľnik 3: Kritické preskúmanie návrhu
alebo "Návrh"
- Definovať správanie sa softvéru. Pre každý prípad použitia:
- Identifikovať správy, ktoré je potrebné posielať medzi objektami a metódy, ktoré túto komunikáciu dovaľujú.
- Pomocou prípadu použitia nakresliť sekvenčný diagram.
- V prípade, ak sa vyskytne potreba doplniť nové objekty alebo atribúty, začleniť ich do diagramu tried.
- Môže sa použiť stavový diagram pre zobrazenie správania sa systému v reálnom čase.
- Uzavrieť statické modelovanie systému (diagram tried)
- Overiť či návrh spĺňa všetky požiadavky na funkčnosť systému.
Míľnik 4: Doručenie
alebo "Implementácia"
- Napísať/vygenerovať programový kód.
- Zaistiť testovanie modulov systému.
- Zaistiť testovanie v prevádzke. Následne ostré nasadenie.
Príklad - Internetová predajňa kníh
Vytvorte systém pre internetovú predajňu kníh. Požiadavky na systém:
- predajňa bude akceptovať objednávky cez internet,
- predajňa bude evidovať používateľské kontá, uvažujme max. 1 000 000 jedinečných zákazníkov,
- používateľské konto bude chránené heslom,
- k dispozícii bude katalógové vyhľadávanie
- k dispozícii bude vyhľadávanie podľa autora, názvu titulu, ISBN čísla a podľa kľúčového slova,
- predajňa bude poskytovať platbu pomocou kreditnej karty; vyžaduje sa zabezpečený presns,
- predajňa bude poskytovať platbu na dobierku,
- predajňa bude mať prepojenie medzi používateľským rozhraním (webom) a skladom,
- predajňa bude mať prepojenie medzi používateľským rozhraním (webom) a informáciami o doručení,
- predajňa bude poskytovať možnosť písať recenzie kníh a všetkým používateľom dovolí tieto recenzie komentovať,
- predajňa bude evidovať hodnotenie kníh od používateľov, resp. zákazníkov.
