Technická univerzita v Košiciach Fakulta elektrotechniky a informatiky Varovný záchranný systém v cestnej doprave Projekt z predmetu Inžinierstvo požiadaviek Bc. Andrej Čalfa, Bc. Dušan Čatloch, 2022 Bc. Michaela Kojnoková, Bc. Martin Kišš, Bc. Kristína Pavličková, Bc. Július Sládek FEI_KPI_IP Obsah Zoznam obrázkov .................................................................................................. 4 1. Štúdia realizovateľnosti .................................................................................. 6 1.1. Základný popis projektu ........................................................................... 6 1.2. Aktuálny stav ............................................................................................ 6 1.3. Požiadavky ............................................................................................... 7 1.3.1. Funkčné požiadavky .......................................................................... 7 1.3.2. Nefunkčné požiadavky ....................................................................... 8 1.4. Konceptuálny model................................................................................. 8 1.5. Typy používateľov systému a ich správanie v systéme ........................... 9 1.6. Odhad nákladov a časový plán ................................................................. 9 1.7. Porovnanie OPCloud vs BridgePoint pre účely štúdie realizovateľnosti 13 2. Dokumentácia požiadaviek pre fázy analýzy a návrhu systému .................. 14 2.1. Analýza a reprezentácie požiadaviek ..................................................... 14 2.1.1. Požiadavky na systém ...................................................................... 14 2.1.2. Požiadavky na používateľa .............................................................. 15 2.1.3. Požiadavky na záchranné zložky ..................................................... 16 2.2. Hlavné artefakty systému ....................................................................... 16 2.3. Prípady použitia ...................................................................................... 17 2.3.1. Prípady použitia pre užívateľa ......................................................... 17 2.3.2. Prípady použitia pre operačné stredisko .......................................... 18 2.4. Model základných objektov a procesov systému v OPCloud ................ 19 2.5. Model bázy dát systému v OPCloud ...................................................... 19 2.6. Objektová štruktúra systému v BridgePoint .......................................... 20 2.7. Porovnanie OPCloud vs BridgePoint pre účely analýzy a návrhu systému ............................................................................................................ 21 3. Dokumentácia k využitiu modelov ............................................................... 22 3.1. Návod na použitie modelov pre verifikáciu návrhu ............................... 22 3.1.1. Vyhodnotenie použitia v projekte .................................................... 22 3.2. Návod pre použitie modelov pre validáciu návrhu ................................ 23 2 FEI_KPI_IP 3.2.1. Vyhodnotenie použitia v projekte .................................................... 23 3.3. Návod na použitie modelov pre generovanie artefaktov cieľového systému ............................................................................................................ 24 3.3.1. Vyhodnotenie použitia v projekte .................................................... 24 3.4. Porovnanie možností použitých CASE systémov pre modelovanie požiadaviek ...................................................................................................... 25 3.4.1 BridgePoint ...................................................................................... 25 3.4.2 OPCloud ........................................................................................... 25 Bibliografia ......................................................................................................... 26 3 FEI_KPI_IP Zoznam obrázkov Obrázok 1 - Doménové hodnoty [1] ................................................................... 10 Obrázok 2 - Faktory zložitosti systému .............................................................. 10 Obrázok 3 - Počet riadkov kódu ......................................................................... 11 Obrázok 4 - Manažment ľudských zdrojov [2]................................................... 11 Obrázok 5 - Tabuľkové zobrazenie využitia ľudských zdrojov ......................... 12 Obrázok 6 - Ganttov diagram ............................................................................. 12 Obrázok 7 - Prípady použitia pre použíávateľa .................................................. 17 Obrázok 8 - Prípady použitia pre operačné stredisko ......................................... 18 Obrázok 9 - Model základných objektov a procesov ......................................... 19 Obrázok 10 - Model bázy dát systému ............................................................... 20 Obrázok 11 - Objektová štruktúra systému ........................................................ 20 Obrázok 12 - Vygenerovaný OPL pre model základných objektov a procesov systému ................................................................................................................ 22 Obrázok 13 - Objektová štruktúra systému (pre overenie) ................................. 23 4 FEI_KPI_IP Zoznam tabuliek Tabuľka 1 - Požiadavky na systém ..................................................................... 14 Tabuľka 2 - Požiadavky na používateľa ............................................................. 15 Tabuľka 3 - Požiadavky na záchranné zložky .................................................... 16 5 FEI_KPI_IP 1. Štúdia realizovateľnosti 1.1. Základný popis projektu Systém OnBoard bol vynájdený za účelom rýchlej identifikácie nehody a pomoci ľuďom vo vážnych dopravných nehodách. Systém OnBoard umožňuje zabezpečiť bezplatné volanie na tiesňovú linku v prípade vážnej dopravnej nehody. OnBoard je možné aj manuálne aktivovať stlačením tlačidla pre okamžité spojenie s centrom pomoci. Týmto systémom skrátime čas, ktorý je potrebný na záchranu ľudského života pri vážnych autonehodách a to tak, že systém sa automaticky zapne pri silnom náraze a odošle údaje o mieste a čase nehody, a smeru jazdy vozidla záchranným zložkám. 1.2. Aktuálny stav Pri analýze súčasného stavu systému OnBoard sme po konzultácií so zákazníkom vzali do úvahy nové skutočnosti a dospeli k tomuto záveru: Získanie informácií o aktuálnom stave Vodič, ktorý umiera na kraji cesty po fatálnej nehode, ktorú si nikto uprostred noci nevšimol, auto, ktoré sa rúti do stromov, čelné nárazy auta... to všetko sú príklady nedávnych dopravných nehôd, pri ktorých by rýchla reakcia záchranných zložiek mohla znamenať veľa - záchranu ľudského života. Aktuálna situácia je opísateľná veľmi jednoducho – ak okolo Vás nikto nie je, ste odsúdení na čakanie a to z hľadiska bezpečnosti a záchrany nie je vôbec ideálne. Tento problém sa snažili rozlúsknuť odborníci po celom svete a my sme prišli s riešením. Aplikácia OnBoard poskytuje automaticky pohotovostné služby pre dopravné nehody bez toho, aby vodič alebo pasažieri museli urobiť čokoľvek manuálne. Predpokladá sa, že čas príchodu záchrannej služby sa zredukuje viac než o 50%. Funguje prostredníctvom palubných jednotiek založených na čipovej technológií, ako je napríklad spoločnosť NXP a využíva internú SIM kartu a mobilnú sieť na automatické odoslanie správy polohy do národného strediska záchranných služieb, ktorá vyšle na pomoc záchrannú jednotku lokalizovanú najbližšie danej nehode. Túto technológiu navrhujeme povinne umiestniť do každého auta vyrobeného od roku 2023, pretože sa očakáva, že prudko zníži počet smrteľných nehôd na cestách. Problémom je, že nie každý človek si vie v stresovej situácií, ako je napríklad dopravná nehoda zachovať chladnú hlavu. Produkt OnBoard môže výrazne 6 FEI_KPI_IP pomôcť. Predstavte si sekundy, ktoré delia daného človeka od smrti. A teraz si predstavte ako by ste reagovali vy, keby ste účastníkom dopravnej nehody. Dokázali by ste presne navigovať záchranné zložky na miesto nehody a urobiť to včas? Podľa prieskumu, ktorý vykonávala naša spoločnosť, až 75% ľudí si netrúfa potvrdiť výrok “ Zvládol by som to na jednotku.” Zvyšných 15% ľudí odpovedalo rázne NIE a len 10% ľudí si bolo istých, že by vedeli zareagovať správne. Avšak 100% ľudí z opýtaných potvrdilo, že OnBoard považujú za nutnú pomoc pri riešení vážnych dopravných nehôd a malo by byť súčasťou každého vozidla. Získanie informácií o poskytovateľoch záchrannej služby Záchranné jednotky toho majú vždy až nad hlavu. Či už sa jedná o poruchy vedomia, náhle zastavenia dýchania, mŕtvicu, otravu liekmi. Komunikácia so zúčastnenými osobami, ktorí volajú na záchrannú linku pomoci je vždy komplikovaná, pretože človek je vždy pod vplyvom emócií a stresu. To často vyúsťuje do nezrozumiteľného mumlania, plaču, neschopnosti komunikovať stručne a rýchlo. Problémom je, že pri fatálnych nehodách ide často o sekundy, ktoré dokážu rozhodnúť o živote alebo smrti a takáto komunikácia so záchrannou službou tomu nenapomáha. A to hovoríme stále len o prípade, kedy je niekto nablízku. Predstavme si situáciu, že človek havaruje a ostane zranený, v bezvedomí, zakliesnený v aute. Je noc, žiadne autá naokolo. Takýto človek je odsúdený na smrť. Pri rozhovore so záchrannými zložkami sme sa dozvedeli, že mnoho krát boli privolaní na pomoc až neskoro, keď už bol človek pár hodín mŕtvy. Prečo ? Lebo si auto v priekope nikto nevšimol. Záchranné služby z rôznych kútov sveta sa zhodli, že OnBoard by im jednoznačným spôsobom uľahčil prácu, keďže by dostali jasné súradnice miesta nehody a dokázali by tým zachrániť množstvo životov. 1.3. Požiadavky Na základe analýzy užívateľov a komunikácie so zadávateľmi projektu sme stanovili nasledujúce požiadavky, ktoré by mal náš systém obsahovať. 1. 2. 3. 4. 1.3.1. Funkčné požiadavky Systém umožňuje registrovanie a prihlásenie používateľov do systému. Systém poskytuje používateľovi možnosť vyplniť informácie o svojom zdravotnom stave. Systém umožňuje bezplatné volanie na tiesňovú linku. Systém umožňuje používateľovi privolať záchrannú službu pomocou tlačidla. 7 FEI_KPI_IP 5. Systém poskytuje záchranným zložkám polohu užívateľa, čas nehody a informácie o užívateľovi. 6. V prípade život neohrozujúcej nehody, systém umožňuje používateľovi vyplniť informácie pre záchranné zložky ako napr. závažnosť dopravnej nehody, počet zranených a pod. 7. Systém poskytuje notifikácie o približnom príchode záchrannej služby. 8. Systém poskytuje stručné informácie týkajúce sa prvej pomoci. 9. Systém je dostupný na viacerých platformách. 1. 2. 3. 4. 1.3.2. Nefunkčné požiadavky Systém neposkytuje možnosť monetizácie. Systém poskytuje používateľovi presnú polohu záchranných zložiek. Systém poskytuje zálohovanie dát. Systém disponuje zabezpečenie proti útokom. 1.4. Konceptuálny model V systéme sme identifikovali základné entity a ich vlastnosti. Väzby ako aj akcie na daných entitách sú vidieť v konceptuálnom modeli. 8 FEI_KPI_IP 1.5. Typy používateľov systému a ich správanie v systéme V našom systéme sme identifikovali dva typy používateľov a ich nasledovné možné akcie a to: Používateľ Registrovanie sa do systému Prihlásenie / Odhlásenie Vyplnenie informácie o zdravotnom stave Bezplatné volanie na tiesňovú linku Privolanie záchrannej služby Vyplnenie podrobnejších informácii o závažnosti nehody a počte zranených Notifikácia o približnom príchode záchrannej služby Zobrazenie informácii o prvej pomoci Záchranné zložky Registrovanie sa do systému Prihlásenie / Odhlásenie Zobrazenie informácii o zdravotnom stave používateľa Zobrazenie informácii o polohe, čase nehody a používateľovi Zobrazenie podrobnejších informácii o závažnosti nehody a počte zranených 1.6. Odhad nákladov a časový plán Na odhad náročnosti vývoja vhodného systému sme použili Constructive Cost Model (COCOMO). Na základe požiadaviek sme sa pokúsili čo možno najlepšie určiť parametre, na základe ktorých boli vykonané výpočty. Ako prvý sme vykonali výpočet funkčných bodov systému. Systém bude pracovať s nemalým počtom vstupov od používateľov, no zložitosť týchto údajov nie je vysoká. 9 FEI_KPI_IP Obrázok 1 - Doménové hodnoty [1] Ďalším krokom je konkrétnejší opis systému prostredníctvom priradenia dôležitosti rôznym aspektom. Obrázok 2 - Faktory zložitosti systému 10 FEI_KPI_IP Nasleduje tabuľka, ktorá poskytuje možnosť výberu programovacieho jazyka systému. Na základe tejto voľby systém COCOMO vypočíta počet riadkov kódu. Obrázok 3 - Počet riadkov kódu Počet potrebných riadkov kódu bol odhadnutý na číslo 15552. Naše výpočty pokračovali definovaním ďalších faktorov – tento krát berúc do úvahy aj faktory ako ľudské zdroje a časové obmedzenia. Tieto faktory boli definované v COCOMO II modeli. Obrázok 4 - Manažment ľudských zdrojov [2] 11 FEI_KPI_IP Výsledné odhadované hodnoty na potrebné ľudské zdroje pre vývoj systému sú zobrazené na obrázku č. 5. Obrázok 5 - Tabuľkové zobrazenie využitia ľudských zdrojov Vieme teda konštatovať, že na vývoj systému budeme potrebovať niečo málo cez 1 rok a 6 vývojárov. Celý tento proces bude stáť zhruba 205 400 $ (208 289 €). Na zobrazenie časového rozvrhu jednotlivých fáz vývoja systému sme použili Ganttov digram. Obrázok 6 - Ganttov diagram 12 FEI_KPI_IP 1.7. Porovnanie OPCloud vs BridgePoint pre účely štúdie realizovateľnosti Modelovací nástroj OPCloud je prístupný ako webová aplikácia, teda je voľne dostupný online. Jeho výhodou je prívetivé používateľské rozhranie a jednoduchá tvorba diagramov. Nevýhodou tohto systému je, že umožňuje vytvoriť len jeden typ diagramu, čo môže spôsobiť nízku zrozumiteľnosť modelov, nakoľko systém používa iba dva typy objektov – objekty a procesy. Detaily v diagramoch sa modelujú obtiažnejšie, nakoľko je ich modelovanie možné iba pomocou uzlov a hrán. V zásade však vieme konštatovať, že modelovanie jednoduchého komponentového diagramu bolo relatívne jednoduché a rýchle. Modelovací nástroj BridgePoint je taktiež voľne dostupný (open source). Jeho výhodou je to, že nepotrebuje žiadnu inštaláciu, v podstate sa stiahne už hotový nástroj pripravený na prácu. Taktiež tento nástroj ponúka množstvo rôznych funkcií. Napriek tomu bolo modelovanie s týmto nástrojom podstatne zložitejšie a nie všetky modeli bolo možné vytvoriť podľa očakávaní. Komponentový diagram sme vytvorili celkom rýchlo, keďže nástroj sám disponuje komponentovým diagramom a preto sme nemuseli hľadať inú náhradu, ktorá by nám vyhovovala. Ovládanie bolo neintuitívne a niektoré veci boli ťažké na nájdenie, čo zabralo dosť času. Taktiež tu chýba orientačná mriežka na plátne, podľa ktorej by sa dali zarovnávať jednotlivé objekty, keďže bez nej niektoré modely vyzerajú dosť chaoticky a neprehľadne. 13 FEI_KPI_IP 2. Dokumentácia požiadaviek pre fázy analýzy a návrhu systému 2.1. Analýza a reprezentácie požiadaviek 2.1.1. Požiadavky na systém Tieto požiadavky opisujú všeobecnú funkcionalitu a vlastnosti systému. Medzi týmito požiadavky sú ako funkčné, tak i nefunkčné požiadavky. ID Názov požiadavky Referencia Priorita Popis 1 Prihlásenie a registrácia do systému Štúdia realizovateľnosti 1 Pri vstupe do systému bude ponúknuté používateľovi prihlásenie alebo registrácia. 2 Poskytnutie informácií o polohe vozidla, o čase nehody a o používateľovi Štúdia realizovateľnosti 1 Systém poskytne záchranným zložkám informácie o polohe vozidla, čase nehody a o používateľovi 3 Notifikácie o približnom príchode záchrannej zložky Štúdia realizovateľnosti 2 Používateľovi pošle systém notifikáciu o dostupnosti záchranných zložiek 4 Poskytnutie zálohy dát Štúdia realizovateľnosti 3 Systém poskytuje zálohovanie dát. 5 Poskytnutie zabezpečenia proti útokom. Štúdia realizovateľnosti 1 Systém disponuje zabezpečením proti útokom. 6 Poskytnutie stručných informácií o prvej pomoci Štúdia realizovateľnosti 2 Systém poskytuje používateľovi stručné informácie týkajúce sa prvej pomoci. 7 Zabezpečenie ochrany osobných údajov Štúdia realizovateľnosti 1 Šifrovanie komunikácie a údajov. Tabuľka 1 - Požiadavky na systém 14 FEI_KPI_IP 2.1.2. Požiadavky na používateľa Tieto požiadavky opisujú funkcionalitu, s ktorou bude interagovať používateľ. Všetky tieto požiadavky sú funkčnými požiadavkami. ID Názov požiadavky Referencia Priorita Popis 1 Prihlásenie a registrácia do systému Štúdia realizovateľnosti 1 Pri vstupe do systému bude ponúknuté používateľovi prihlásenie alebo registrácia. 2 Vyplnenie informácií o zdravotnom stave Štúdia realizovateľnosti 2 Prihlásený používateľ má možnosť vyplniť informácie o jeho zdravotnom stave, ktoré budú v prípade potreby poskytnuté záchranným zložkám. Napríklad informácie o alergiách, chorobách atď. 3 Bezplatné zavolanie záchrannej služby - automatické Štúdia realizovateľnosti 1 Automatické privolanie záchrannej služby s odoslaním polohy vozidla, času nehody a informácií o používateľovi. 4 Bezplatné zavolanie záchrannej služby - tlačidlom Štúdia realizovateľnosti 1 Privolanie záchrannej služby s odoslaním polohy vozidla, času nehody a informácií o používateľovi po stlačení tlačidla. 5 Notifikácie o približnom príchode záchrannej zložky Štúdia realizovateľnosti 3 Používateľovi pošle systém notifikáciu o dostupnosti záchranných zložiek 6 Poskytnutie stručných informácií o prvej pomoci Štúdia realizovateľnosti 2 Systém poskytuje stručné informácie týkajúce sa prvej pomoci. Tabuľka 2 - Požiadavky na používateľa 15 FEI_KPI_IP 2.1.3. Požiadavky na záchranné zložky Tieto požiadavky opisujú funkcionalitu, s ktorou budú interagovať záchranné zložky. Všetky tieto požiadavky sú funkčnými požiadavkami. ID Názov požiadavky Referencia Priorita Popis 1 Prihlásenie a registrácia do systému Štúdia realizovateľnosti 1 Pri vstupe do systému bude ponúknuté záchrannej zložke prihlásenie alebo registrácia. 2 Zobrazenie informácií o používateľovi Štúdia realizovateľnosti 3 Záchranné zložky si po privolaní používateľom budú môcť zobraziť informácie o používateľovi a o jeho zdravotnom stave, ak tieto informácie používateľ vyplnil. 3 Posielať systému informácie o približnom príchode Štúdia realizovateľnosti 3 Posielanie informácií o príchode na miesto nehody systému. Systém tieto informácie odošle prostredníctvom notifikácií používateľovi. 4 Zobrazenie informácií o polohe a o čase Konzultácia s klientom 5 V prípade nehody bude mať záchranná zložka prístup ku presnej polohe používateľa a o čase nehody. Tabuľka 3 - Požiadavky na záchranné zložky 2.2. Hlavné artefakty systému Aktérmi systému sú vodič vozidla, záchranné zložky a centrálny počítač ktorý zabezpečuje “komunikáciu” medzi používateľom a záchrannými zložkami. Vodič a záchranné zložky po procese registrácie do systému nadobudnú stav “registrovaný” a majú možnosť sa do aplikácie prihlásiť. Po procese prihlásenia sa ich stav v systéme zmení na “prihlásený”, čo zautomatizuje pridanie záznamu o prihlásenom aktérovi do databázy. Od tohto momentu každé manuálne alebo automatické privolanie pomoci vodičom zmení jeho stav na stav “vyžaduje pomoc”. Zmena jeho stavu spôsobí začatie procesu samotnej záchrany - automaticky a neodkladne zalarmuje všetky záchranné zložky, ktorých stav v systéme je “prihlásený”. Ak záchranná zložka má možnosť výjazdu k vodičovi a obdržala už automaticky zasielané informácie o polohe vodiča zmení svoj stav na “poskytujúca pomoc” a začne proces záchrany. To zabráni inému vodičovi kontaktovať tieto už pracujúce zložky a kontaktuje iné, ktoré momentálne nie sú na výjazde. Po ukončení procesu záchrany záchranné zložky označia výjazd za ukončený a zmenia svoj stav na “pripravený poskytnúť pomoc” a vodičov stav je automaticky resetovaný zo stavu “vyžaduje pomoc”. 16 FEI_KPI_IP 2.2.1. Prípady použitia V tejto časti si bližšie popíšeme grafické modely systému. Tieto modely poukazujú na aplikáciu daných požiadaviek priamo do systému. V nasledujúcej kapitole sú použité Use Case diagramy. Pomocou týchto diagramov je možné poukázať na možnosti, ktoré používateľ má k dispozícií a čo dokáže robiť v danom systéme. 2.2.2. Prípady použitia pre používateľa Tento prípad poukazuje na možnosti používateľa. Užívateľ má k dispozícií 4 možnosti. Najzložitejšia je upozornenie záchranných zložiek, ktorá sa ďalej rozvetvuje podľa toho, či sú osoby pri vedomí alebo sú v bezvedomí. V prípade, že osoby sú v bezvedomí, aplikácia odošle polohu a informácie o užívateľovi. V opačnom prípade sa užívateľ dostane do komunikácie priamo s operátorom. Používateľ dokáže v prípade život neohrozujúcej situácie podrobnejšie popísať situáciu, ako napríklad závažnosť situácie, počet zranených a ďalšie. Ďalšia funkcia v aplikácií je poskytnutie približnom čase o príchode záchranných zložiek. Táto informácia sa zobrazuje po upozornení záchranných zložiek a odoslaní zložiek na miesto nehody. Posledná funkcia je zobrazenie informácií o prvej pomoci. Keďže množstvo ľudí neovláda prvú pomoc, táto funkcionalita poskytne informácie pre užívateľov, či už za účelom edukácie alebo potreby takýchto informácií priamo pri nehode. Takéto informácie sú veľmi potrebné, z toho dôvodu to považujeme za veľmi podstatnú časť projektu. Obrázok 7 - Prípady použitia pre používateľa 17 FEI_KPI_IP 2.2.3. Prípady použitia pre operačné stredisko Tento prípad poukazuje na možnosti operačného strediska. Operačné stredisko má taktiež k dispozícií 4 funkcie. Prvá je notifikácia o nehode. Akonáhle systém vyhodnotí, že došlo k nehode, systém operátora na toto upozorní prostredníctvom notifikácie. Druhá možnosť je zoznam dostupných zložiek. V tejto časti sú operátorovi poskytnuté všetky informácie o zložkách, ako napríklad počet dostupných zložiek, ich polohu a predpokladaný čas príjazdu. Po odoslaní zložiek operátor taktiež dokáže sledovať vyslané zložky aby vedel informovať osobu, ktorá zložky zavolala. Poslednou možnosťou operátora je poskytovanie informácií, či už pre záchranné zložky, ale taktiež pre účastníkov nehody. Obrázok 8 - Prípady použitia pre operačné stredisko 18 FEI_KPI_IP 2.3. Model základných objektov a procesov systému v OPCloud Pre náš systém sme vytvorili pomocou systému OPCloud aj model základných objektov a procesov. Tento model obšírne poukazuje na systém ako celok. Ako možno vidieť na obrázku 9., náš systém obsahuje dvoch používateľov a to vodiča ako používateľa systému a záchrannú zložku zasahujúcu pri nehode. Obaja títo používatelia interagujú so systémom pomocou istých procesov, ktoré sú rozličné pre vodiča a pre záchranné zložky. Okrem týchto artefaktov nám tento model poukazuje aj na údaje ktoré obsahuje samotná dopravné nehoda. Obrázok 9 - Model základných objektov a procesov 2.4. Model bázy dát systému v OPCloud Medzi dôležitú časť nášho systému nepodmienene patrí aj samotná báza dát. Na obrázku 10. možno vidieť zloženie príslušnej databázy. A teda naša databáza obsahuje samotné núdzové volania, záchranné zložky, a vodičov. Okrem samotnej štruktúry možno vidieť aj jednotlivé procesy ako vytvorenie núdzového hovoru, začatie procesu záchrany, či registrácia do systému, ktoré dané entity napĺňajú. 19 FEI_KPI_IP Obrázok 10 - Model bázy dát systému 2.5. Objektová štruktúra systému v BridgePoint Z hľadiska lepšieho pochopenia samotnej štruktúry systému sme vytvorili model objektovej štruktúry. V tejto časti sme využili nástroj BridgePoint, kde sme použili diagram tried. Na obrázku 11. možno vidieť z akých objektov je náš systém pozostáva. Tieto objekty sú medzi sebou poprepájané linkami, ktoré vyjadrujú kardinalitu medzi objektami v systéme. Okrem týchto vzťahov na príslušnom obrázku možno vidieť aj jednotlivé atribúty resp. operácie pre dané objekty. Obrázok 11 - Objektová štruktúra systému 20 FEI_KPI_IP 2.6. Porovnanie OPCloud vs BridgePoint pre účely analýzy a návrhu systému Jednou z veľkých predností systému BridgePoint je, že obsahuje širokú škálu UML modelov, pomocou ktorých môžeme vytvárať rôzne modely pre modelovanie systémov. Okrem týchto rôznych modelov obsahuje BridgePoint aj bohatú paletu rôznych funkcií, ako je napríklad samotná simulácia. Medzi nedostatky BridgePoint-u patrí nutná znalosť jednotlivých diagramov, takže nie každý diagram možno jednoducho pochopiť bez toho, aby používateľ napríklad vedel, ktorá entita čo predstavuje. Pri použití systému OPCloud je veľkou výhodou samotné OCL, ktoré generuje textové znázornenie nami vytvorených diagramov, takže používateľ nemusí poznať grafické znázornenie jednotlivých objektov, procesov a ich význam. Ako nevýhodu jednoznačne vnímame to, že v systéme možno modelovať len prostredníctvom jedného druhu diagramu. 21 FEI_KPI_IP 3. Dokumentácia k využitiu modelov Táto časť nášho projektu sa zaoberá využitím modelov pre verifikáciu, validáciu a následné generovanie artefaktov cieľového systému. V závere popisujeme porovnanie modelovania požiadaviek pomocou využívaných systémov OPCloud a BridgePoint. 3.1. Návod na použitie modelov pre verifikáciu návrhu 3.1.1. Vyhodnotenie použitia v projekte Verifikácia modelu je v kontexte počítačovej simulácie proces potvrdenia, že je správne implementovaný vzhľadom na koncepčný model. Počas overovania sa model testuje, aby sa našli a opravili chyby pri implementácii modelu. Používajú sa rôzne procesy a techniky, aby sa zabezpečilo, že model zodpovedá špecifikáciám a predpokladom s ohľadom na koncept modelu. Cieľom overenia modelu je zabezpečiť, aby implementácia modelu bola správna. [3] Verifikáciu nám značne uľahčil OPL generovaný OPCloud-om, ktorý generuje jednoduché vety opisujúce systém. Tieto tvrdenia sme následne porovnali s požiadavkami a na základe vysokej zhody sme usúdili, že verifikácia bude s najväčšou pravdepodobnosťou úspešná. Obrázok 12 - Vygenerovaný OPL pre model základných objektov a procesov systému 22 FEI_KPI_IP Pre uistenie sa, že naše zistenie bolo korektné, rozhodli sme sa náš systém verifikovať aj pomocou modelu programu BridgePoint. V tomto modeli sme sa zamerali na pozorovanie vzťahov a vlastností objektov. Obrázok 13 - Objektová štruktúra systému (pre overenie) 3.2. Návod pre použitie modelov pre validáciu návrhu 3.2.1. Vyhodnotenie použitia v projekte Validácia kontroluje presnosť reprezentácie modelu reálneho systému. Validácia modelu je definovaná ako „potvrdenie, že počítačový model v rámci svojej oblasti použiteľnosti má uspokojivý rozsah presnosti v súlade so zamýšľanou aplikáciou modelu“. [3] Preukázanie, že model sa v rámci svojej oblasti použiteľnosti správa s uspokojivou presnosťou v súlade s cieľmi modelu a simulácie. Validačná fáza sa zameriava na zhodu medzi pozorovaným správaním prvkov systému s príslušnými prvkami simulačného modelu systému a na určenie, či sú rozdiely prijateľné vzhľadom na zamýšľané (cieľové) použitie modelu. Ak sa nedosiahne uspokojivá zhoda, model sa upraví tak, aby bol v užšej zhode s pozorovaným správaním skutočného systému (alebo sa identifikujú a 23 FEI_KPI_IP opravia chyby v pozorovaní/experimentácii modeloch/analýzach). [4] alebo referenčných Na zostavenie konceptuálneho modelu a overenie modelu musí byť k dispozícii dostatočné množstvo vhodných údajov. Nedostatok vhodných údajov je často dôvodom zlyhania pokusov o overenie modelu. V rámci overenia miery splnenia nastavených cieľov je dôležité položiť si nasledujúce otázky: Pre koho a na čo je systém určený ? o Náš systém je určený pre každého vodiča vozidla na cestných komunikáciách. V momentoch, kedy dôjde k dopravnej nehode a častokrát o osude človeka rozhodujú sekundy je dôležitá pohotová reakcia. Tú zabezpečí práve náš navrhovaný systém. Vodič vozidla môže záchranné zložky alarmovať manuálnym stlačením tlačidla alebo sa zložky alarmujú automaticky po zaznamenaní nárazu vozidla. Aké sú ciele systému ? o Hlavným cieľom systému je zabezpečenie čo najrýchlejšej záchrany ľudského života v tiesni. Chceme teda poskytnúť vodičom vhodnú funkcionalitu vozidla, ktorá bude zodpovedná za promptné privolanie pomoci. Sú všetky ciele zahrnuté v požiadavkách systému ? o Áno. Na základe získanej spätnej väzby je možné ďalej postupovať s úpravou nedostatkov. Keďže proces validácie prebieha pravidelne, po úspešnej validácií je možné posunúť sa pri tvorbe systému ďalej. 3.3. Návod na použitie modelov pre generovanie artefaktov cieľového systému 3.3.1. Vyhodnotenie použitia v projekte Program BridgePoint môže značne uľahčiť implementáciu navrhnutého systému tak, že z modelu objektovej štruktúry systému vie vygenerovať šablónu tried pre objektovo orientované jazyky, pričom zachová jednotlivé vlastnosti a prepojenia rôznych tried. 24 FEI_KPI_IP OPCloud je nápomocný najmä pri tvorbe bázy dát. Na základe modelu dokáže generovať nielen základné entity databázového systému, no i špecifické príkazy použiteľné nad príslušnými entitami. 3.4. Porovnanie možností použitých CASE systémov pre modelovanie požiadaviek Pri práci na tomto projekte sme si využili dva programy – BridgePoint a OPCloud. Pri návrhu takéhoto systému oba veľmi užitočné, no zároveň veľmi odlišné a každý poskytoval nástroje na grafické spracovanie inej časti. 3.4.1 BridgePoint Program BridgePoint poskytuje možnosť modelovať systém pomocou veľkého množstva rôznych diagramov. Najzaujímavejším z nich je bezpochyby diagram xtUML, ktorý je spustiteľný a jeho funkcionalita značne uľahčuje validáciu namodelovaného systému. BridgePoint tiež umožňuje generovanie kódu z vytvorených diagramov, čo veľmi užitočné pri samotnej implementácii systému – táto funkcionalita nielen šetrí čas, ale taktiež eliminuje chyby, ktoré by mohli vzniknúť pri manuálnej implementácii. Najväčšou nevýhodou BridgePointu je user experience, najmä neprehľadné a jemne zastaralé UI. 3.4.2 OPCloud OPCloud umožňuje tvorbu iba jedného typu modelu, no tvorba tohto modelu je vskutku jednoduchá vďaka prehľadnému a zrozumiteľnému UI. Vytvorené modely sú o čosi zrozumiteľnejšie i pre ľudí mimo vývojárskeho tímu a vety generované v jazyku OPL veľkým prínosom najmä pri verifikácii systému. Ďalším plusom je to, že OPCloud je – ako už jeho názov napovedá – cloudovým systém a teda nie je nutné ho sťahovať, či inštalovať. Najväčšou nevýhodou je možnosť tvorby iba jedného modelu, je síce nápomocným pri verifikácii, no jeho prínos v ostatných fázach návrhu je obmedzený. Výhody systému Bridgepoint - nápomocné pre developerov - je možné modelovať systém detailnejšie Nevýhody systému Bridgepoint - pre spustenie je potrebná Java - komplikované pre používanie - je potrebné inštalovať - je potrebné mať určité znalosti Výhody systému OPCloud Nevýhody systému OPCloud 25 FEI_KPI_IP - Nie je potrebné inštalovať - Online nástroj - Jednoduchšie používateľské rozhranie - Jednoduchšie na ovládanie - Generuje výstup diagramov (vysvetlivky) - nie je vhodný pre ďalší vývoj - iba OPD Bibliografia [1 „COCOMO,“ [Online]. Available: ] http://groups.umd.umich.edu/cis/course.des/cis525/js/f00/gamel/cocomo.ht ml. [2 „COCOMO II,“ [Online]. Available: ] http://softwarecost.org/tools/COCOMO/. [3 „Verification and validation of computer simulation models,“ [Online]. ] Available: https://en.wikipedia.org/wiki/Verification_and_validation_of_computer_sim ulation_models. [4 „Mitre,“ [Online]. Available: https://www.mitre.org/our-impact/mitre] labs/systems-engineering-innovation-center. 26