Softvér všeobecne a vlastnosti PDF

Softvér všeobecne a vlastnosti 1. Čo je softvérové inžinierstvo? Systematický prístup k vývoju, nasadeniu a údržbe SW Inžinierska disciplína zaoberajúca sa praktickými problémami vývoja rozsiahlych SW systémov 1.1 Prečo vytvárame softvér? Zlepšenie služieb (informačné systémy) Znižovanie...

Softvér všeobecne a vlastnosti 1. Čo je softvérové inžinierstvo? Systematický prístup k vývoju, nasadeniu a údržbe SW Inžinierska disciplína zaoberajúca sa praktickými problémami vývoja rozsiahlych SW systémov 1.1 Prečo vytvárame softvér? Zlepšenie služieb (informačné systémy) Znižovanie nákladov (riadenie výroby) Nemožnosť riešenia bez použitia počítačov (predpoveď počasia) Je nutné zlepšovať vlastnosti SW, hlavne spoľahlivosť, bezpečnosť a použiteľnosť, potreba zvyšovať produktivitu vývoja SW 2. Popíš softvérovú krízu z 60. rokov. Prejavovala sa a stále sa prejavuje neúnosným predlžovaním a predražovaním projektov, nízkou kvalitou výsledných produktov, problematickou údržbou a nízkou produktivitou prace programátorov Hľadanie riešenia týchto problémov viedlo k zavedeniu štruktúrovaného programovania 3. Čo je softvérový produkt? Zbierka počítačových programov, procedúr, pravidiel a s nimi spojená dokumentácia Členovia jednej komunity (programátori) vytvárajú SW (výrobok) pre inú skupinu ľudí (zákazníci). SW produkt nie je len samotný program ale aj požiadavky, špecifikácie, popisy návrhu, zdrojové texty, testovacie dáta, príručky, manuály Aktéri vo vývoji SW produktu - zákazník (sponzor, špecifikuje požiadavky na SW), dodávateľ (vyvíja systém, komunikuje s užívateľom), užívateľ (testuje, používa systém) 4. Generický a zákaznícky SW Genericky (krabicový) SW: predáva sa ľubovoľnému záujemcovi, musí sa dobre otestovať pred predajom, dodatočné opravy sú náročné Zákaznícky SW: šitý na mieru konkrétnemu zákazníkovi, cena je vyššia, typické pre systémy riadenia výroby 5. Kvalita SW produktu. Je to súhrn vlastností a charakteristík výrobku, procesu alebo služby, ktorý ukazuje jeho schopnosť plniť určené alebo odvodené potreby Nie je definovaná ako absolútna miera ale ako stupeň splnenia požiadaviek a potrieb (miera stupňa dokonalosti) 6. Správnosť SW Do akej miery SW vyhovuje špecifikácii 7. Spoľahlivosť SW Pravdepodobnosť, že SW bude v danom čaše vykonávať zamýšľanú funkciu 8. Efektívnosť SW Splnenie kritérií na využitie zdrojov počítačového systému, na čas potrebný na realizáciu a ďalších kritérií (náklady) 9. Použiteľnosť SW Úsilie vynaložené na to, aby sa dal SW používať 10. Bezpečnosť SW Miera odolnosti voči neoprávneným zásahom do systému 11. Prenositeľnosť SW Aké veľké úsilie je potrebné pre prenos na inú platformu 12. Znovupoužitelnosť SW Do akej miery je možné znovu použiť jednotlivé časti SW 13. Interoperabilita SW Úsilie potrebné na zaistenie spolupráce s inými systémami 14. Udržovateľnosť SW Schopnosť SW reagovať na meniace sa potreby zákazníka alebo zmeny legislatívy 15. Testovateľnosť SW Úsilie nutné na testovanie vlastností SW 16. Dokumentovanosť SW Miera, do akej sú všetky rozhodnutia pri vývoji SW zdokumentované a kontinuita dokumentácie 17. Popíš proces vývoja SW Analýza a špecifikácia požiadaviek (8%): zákazníkove požiadavky sú zapísané do štruktúrovanej podoby, pozornosť je venovaná samotným požiadavkám, nie ich realizácii, do tejto etapy patri aj štúdia vhodnosti a analýza rizík, CIEĽ: stanovenie služieb, ktoré zákazník požaduje od systému a určenie podmienok jeho vývoja a prevádzky Architektonicky návrh (7%): ujasnenie koncepcie systému, dekompozícia, plánuje sa akceptačné testovanie a nasadenie do prevádzky, školenia užívateľov Podrobný návrh: podrobná špecifikácia súčastí systému, výber algoritmov, stanovenie štruktúry dát, ošetrovanie chýb, špecifikujú sa požiadavky na ľudské zdroje, odhaduje sa doba trvania a náklady na projekt. Plánuje sa návrh testu súčastí vrátané testovacích dát Implementácia a testovanie súčasti (12%): programová realizácia, vypracovanie dokumentácie, otestovanie súčastí Integrácia a testovanie systému (6%): spojenie súčastí do jedného celku, otestovanie celého systému, oprava chýb, ktoré sa predtým neobjavili Akceptačné testovanie a inštalácia: otestovanie zákazníkom/užívateľom, školenie užívateľov po akceptácii Prevádzka a údržba (67%): zabezpečenie prevádzky SW, priebežné riešenie ďalších problémov, ktoré sa predtým neprejavili, opravy, rozširovanie a prispôsobovanie SW 18. Popíš problémy pri vývoji SW Zložitosť - nie je možné pochopiť všetky možné stavy systému a dôsledky úprav, žiadne dve časti nie sú rovnaké, zložitosť je zdrojom ďalších problémov (komunikácia v tíme) Prispôsobivosť - pri zmene by sa mal zmeniť SW nie naopak Nestálosť - pribúdajúce požiadavky, zmena SW v závislosti od okolia Neviditeľnosť - nie sme schopní určiť, čo chýba v reprezentácii SW výrobku Syndróm 90% hotovo - pri posudzovaní hotovej časti sa vychádza z odpracovaného podľa plánu a nie podľa skutočne hotového Špecifikácia Náchylnosť SW k chybám - niektoré sa prejavia až počas prevádzky a nie počas vývoja Práca v tíme - komunikačné problémy Dokumentácia - u veľkých projektov náročné na udržanie aktuálnosti Starnutie SW - postupne pridávanie nových funkcii a časte opravy vedú k degradácii systému Syndróm 2. systému - autor ma úspešný 1. produkt , snaží sa vytvoriť druhy dokonalý - ten je často príliš zložitý a nepochopiteľný a neefektívny Menej časté problémy: nízka znovupoužiteľnosť pri tvorbe SW problém miery tvorba dokumentácie - problematická udržovateľnosť aktuálnosti náchylnosť SW k chybám - veľa sa prejaví pri chode, nie pri vývoji SW spôsob starnutia SW 19. Krivka starnutia SW Manažment vývoja softvéru 20. Popíš Manažment Manažment je proces koordinácie činností skupiny ľudí, ktorý sa realizuje za účelom dosiahnutia stanoveného cieľa 21. Popíš hlavné ciele SW inžinierstva Manažment projektu - riadenie životného cyklu projektu, efektivita práca - čas Techniky - analýzy, návrhu, programovania, testovania.. 22. Vlastnosti SW inžiniera – základné znalosti, schopnosť aplikovať znalosti, schopnosť získavať nové znalosti 23. Popíš Demingov manažérsky cyklus (PDCA) Plánovanie (plan) – plánovanie zlepšenia Zavádzanie (do) – realizácia plánu Overenie (check) – zhodnotenie výsledkov Jednanie (act) – rozhodnutie o ďalších zmenách 24. Popíš Projekt. Projekt je časovo ohraničené (úsilie) - každý projekt ma svoj začiatok a koniec, koniec projektu - keď sú dosiahnuté stanovené ciele Je jedinečný (výsledok) - výsledok projektu sa líši od iných projektov 25. Popíš Procesy manažmentu projektu Inicializácia - rozpoznanie, že projekt môže začať, získanie všetkých relevantných informácií (časový cenový horizont, potenciálne riziká), zdroj inicializácie - požiadavky zákazníka, dopyt na trhu, výhody technológie Plánovanie - vytvorenie a udržovanie plánu pre bezpečný chod projektu, definícia požiadaviek na zdroje, prácu, kvantitu práce a kvalitu; je podrobné Riadenie - kontrola a riadenie v závislosti od výkonu, zhromažďovanie a rozširovanie informácií o projekte, sledovanie stavu projektu Prevádzanie - najviac času a peňazí, realizácia plánu projektu, prideľovanie úloh manažérom, koordinácia úloh a priorít, vytvára sa výsledok (výrobok, služba) Ukončenie - zaznamenanie poznatkov, skúseností, poučení pre budúce projekty, ukončenie kontraktu s dodávateľmi 26. Čo je softvérový proces? Definuje kto má kedy čo robiť, aby boli splnené požiadavky 27. Popíš životný cyklus softvéru Rozdeľuje proces vývoja SW na obdobia (etapy) s daným cieľom: Analýza a špecifikácia požiadaviek (8%) Architektonicky návrh a podrobný návrh (7%) Implementácia a testovanie súčasti (12%) Integrácia a testovanie systému (6%) Prevádzka a údržba (67%) 28. Popíš Proces vývoja softvéru Proces, v ktorom: sa potreby užívateľa transformujú na požiadavky na SW požiadavky na SW sa transformujú na návrh návrh sa implementuje implementácia sa testuje produkt sa dodá užívateľovi 29. Popíš dekompozíciu problémov Rozdelenie (dekompozícia) zložitého problému na jednoduchšie Prináša: ľahšie zvládnuteľné systémy, pozornosť na jeden podsystém, vývoj podsystémov nezávisle od seba, veľké systémy sa bez dekompozície nedajú zvládnuť 30. Popíš implementáciu zhora-nadol a zdola-nahor Zhora-nadol: najprv sa vytvoria moduly na najvyššej úrovni a postupne moduly nižších vrstiev, systém je možné skôr testovať ako celok a vážne chyby sú včas odstránené, nevýhoda je že je potrebné simulovať podsystémy, ktoré ešte nie sú vytvorené, testovanie logiky systému je náročnejšie ako testovanie jednotlivých modulov Zdola-nahor: najprv najnižšie moduly, odladia sa a využívajú sa na tvorbu na vyššej úrovni, nevýhoda je že chyby sa prejavia neskôr - v etape integračného testovania, testovanie modulov jednotlivo je jednoduchšie ako celej logiky systému 31. Popíš analýzu a špecifikáciu požiadaviek Stakeholder - zainteresovaná strana v projekte = zákazník, užívateľ, analytik, návrhár, tester, manažér.. Je dôležité zapojiť nielen zákazníka, ale identifikovať všetkých stakeholderov a zapojiť ich do projektu Získavanie informácií - cieľ projektu, interview, užívateľské požiadavky Analýza - vhodnosť, modelovanie, prototypovanie Špecifikácia - transformácia informácií z analýzy do dokumentu Validácia - vyhodnocovanie požiadaviek, simulovanie, prototypovanie 32. Popíš Typy požiadaviek Obchodné - prečo zákazník potrebuje systém, obchodné ciele - úspora nákladov, úspora času Užívateľské - čo sa dá so systémom robiť, úlohy, ktoré vykonáva užívateľ Funkčné - čo musí byť vykonané, aby mohli byť vykonané úlohy (user requirements) a tým splnené obchodné požiadavky (business requirements), chovanie systému v rôznych podmienkach (NAPR: čo všetko treba zistiť pre zistenie dostupnosti lieku, chemikálie, čo všetko je treba zistiť pre rezerváciu knihy o užívateľovi) Nefunkčné - vlastnosti a charakteristiky, ktoré musí systém splňovať a rešpektovať obmedzenia požiadavky na prevádzku systému (statické - napr. počet užívateľov, dynamické - napr. čas odozvy) požiadavky na výsledný systém (počiatočné vybavenie - napr. HW náročnosť; programové vybavenie - napr. operačný systém; vyvíjaný softvér - napr. efektívnosť, spoľahlivosť) požiadavky na vývojový proces - dodržiavanie pravidiel, odovzdanie systému požiadavky na rozhranie - SW - User, SW – HW externé požiadavky - legislatíva (ochrana informácií..) 33. Popíš problémy pri špecifikácii požiadaviek Prirodzená neúplnosť a nepresnosť požiadaviek zákazníkom, nepresná formulácia Nedostatok znalostí analytika (neznalosť analyzovanej oblasti, terminológie), zákazníka (neznalosť vývoja SW, terminológie) Nekonzistentné požiadavky - rôzni užívatelia - rôzne požiadavky (aj medzi zákazníkom a užívateľom) Ďalšie problémy - problémy s testovaním a validáciou požiadaviek: Vyradenie - v dobe špecifikácie je nejaká entita implicitná, ale s odstupom čašu sa môže vytratiť Deformácia - získaná informácia môže zavádzať Zobecnenie - veta je príliš všeobecná, preto je nepravdivá 34. Popíš Dobrú špecifikáciu požiadaviek Zoradená podľa dôležitosti Sledovateľná Modifikovateľná - jednoduché úpravy a dopĺňanie požiadaviek Jednoznačná - zmysel požiadavky je jasný Úplná - obsahuje všetky dôležité požiadavky Konzistentná - požiadavka nie je v rozpore s inou požiadavkou Verifikovateľná - merateľnosť splnenia požiadaviek 35. Popíš Dátové modelovanie Mať v systéme všetky potrebné dáta Nemať v systéme žiadne nepotrebné dáta Vyjadriť vzťahy medzi dátami Popísať transformovanie dát v systéme Entita - objekt, rozlíšiteľný od iných objektov Entitná množina - množina entít rovnakého typu (zdieľajú atribúty) Atribút - vlastnosť entity, ktorá nás zaujíma: Prázdne (NULL), Jednohodnotové, Viachodnotové (telefón), Odvodené (datumNarodenia->vek) Vzťah - asociácia medzi entitami Vzťahová množina - množina vzťahov, ktoré zdieľajú vlastnosti 36. Popíš Prístupy k analýze a návrhu Štruktúrovaný - systém chápaný ako komplex procesov, ktoré operujú nad dátami Konceptuálny model - podstata systému, Data flow diagram Logický model - implementácia konceptuálnej štruktúry Fyzický model - fyzické usporiadanie dát (súbory) Objektovo orientovaný - systém chápaný ako komplex vzájomne komunikujúcich objektov objektovo orientované prostriedky (objekty, triedy, UML) a metodiky (RUP) vyššia stabilita navrhovaných prvkov Objekt má rolu, identitu, má metódy, uchováva dáta, spracuje a odosiela správy 37. Popíš doménový model Model analytických tried, nájdenie abstrakcií v problémovej doméne, use-case používa pojmy z doménového modelu, zobrazuje len podstatné veci z hľadiska problémovej domény Doménový model nie je dátový, nemusí mať atribúty ani stálosť dát Pomenováva koncepty doménového systému 38. Popíš konceptuálnu triedu Len najpodstatnejšie atribúty a operácie, obsahuje malú správne definovanú množinu zodpovedností, minimum väzieb na iné analytické triedy Trieda má 3-5 zodpovedností, každá spolupracuje s inou triedou, pozor na veľa malých tried a malý počet komplexných tried, názov triedy vymedzuje jej účel (NakupnyKosik) Spojujeme asociácie, nie atribúty Modely SW systémov Lineárne modely 39. Popíš vodopádový/ lineárny model základný model, etapy sú lineárne za sebou (od prvej etapy po poslednú) možnosť návratu k predošlej etape, neodpovedá vývoju reálnych projektov výhody: jednoduchý na riadenie, ak sú požiadavky nemenné tak je ideálny nevýhody: zákazník nie je nikdy schopný vopred stanoviť presné požiadavky, pri zmenách sa dlho realizujú, zákazník vidí spustiteľnú verziu až v neskorších etapách vývoja - príliš neskoro na odhalenie nedostatkov 40. Popíš V-model Je to varianta vodopádového modelu s väčším dôrazom na testovanie V symbolizuje grafické usporiadanie etáp, V ako verifikácia a validácia, ľavá časť - vývojové aktivity, plánovanie testov, pravá časť - testovanie podľa plánu 41. Popíš W-model Vychádza z V modelu Aktivity spojené s testovaním sú na rovnakej úrovni ako návrhové aktivity (druhé súbežné V), ľavá strana - overovanie, plánovanie a návrh testov, pravá strana - testovanie, zmeny kódu, regresívne testovanie Iteratívne modely 42. Popíš iteratívne modely proces vývoja je rozdelený do iterácií, jednotlivé iterácie sú vlastne vodopády, po každej iterácii má užívateľ k dispozícii neúplnú verziu na otestovanie výhody - zákazník ma možnosť validovať výsledok nevýhody - náročnejší na riadenie, potenciálne horšia výsledná štruktúra, nie je to ucelený model, je súčasťou iných systémov 43. Popíš inkrementálny model Kombinácia lineárneho a iteratívneho modelu, na základe celkovej špecifikácie sa stanovia ucelené časti systému Môže to byt buď séria vodopádov pre každú súčasť systému, alebo napríklad špecifikácia a návrh vodopádom a nasleduje iteratívny prístup kombinovaný s prototypovaním Výhody - Jednoduché zavedenie zmien počas vývoja Nevýhody - vývoj po častiach môže viest k strate vnímania logiky celku 44. Popíš špirálový model Kombinácia prototypovania a analýzy rizík - Jednotlivé etapy sa neustále opakujú, vždy na vyššom stupni Medzníky (Milestones) - prevzaté metodikou RUP: o Life Cycle Objectives - vyhodnotenie cieľa projektu, všetky požiadavky sú stanovené; cena, plán a priority zodpovedajú zámerom, identifikované riziká o Life Cycle Architecture - vyhodnotenie výberu architektúry, riešenie rizík, požiadavky a architektúra sú stabilné o Initial Operation Capability - systém pripravený na distribúciu pre uživateľské testovanie, stabilná verzia pre testovanie zákazníkom Výhody - vhodný pre zložité projekty, nezávislý na metodológii, chyby a nevyhovujúce postupy sú hneď odhalené Nevýhody - analýza rizík musí byť na vysokej úrovni, problematické plánovanie termínov a cien, vyžaduje neustálu spoluprácu so zákazníkom, SW je k dispozícii až po poslednom cykle Analýza rizík: cieľom je odhaliť možné ohrozenia projektu (odchod ľudí, zníženie rozpočtu, zlyhanie HW, nezáujem o produkt) a pripraviť na ne reakcie 45. Popíš prototypovanie nie je to ucelený model, je súčasťou iných systémov prototyp: čiastočná implementácia produktu, prezentuje vonkajšie rozhranie(validácia), ďalej sa nepoužíva Metodiky vývoja SW 46. Metodiky vývoja SW venujú sa aspektom, ktoré ovplyvňujú vývoj SW produktu (proces tvorby SW..) Metóda - postup pre dosiahnutie určitého cieľa Metodika - súhrn doporučených praktík a postupov Metodológia - náuka o metódach, ich tvorbe a použitia = Software Development Methodology 47. Popíš Agilné metodiky a Heavyweight metodiky Agilné Minimum byrokracie Doraz na komunikáciu v tíme Čo najrýchlejšie vyvinúť SW, čakať na spätnú väzbu od zákazníka Dôraz na testovanie zákazník je ochotný sa zapojiť do vývoja Adaptívny prístup - meniaca sa s požiadavkami, malé projekty a malé tímy, decentralizované riadenie, malý objem dokumentácie, people-oriented, kritérium: čas a zdroje, premenné kritérium: funkcionalita - neurčitý rozpočet Heavyweight Prediktívny prístup, známe a stabilné požiadavky Pevný rozsah projektu veľké projekty a veľké tímy, centralizované riadenie, veľký objem dokumentácie, process-oriented, kritérium: funkcionalita, premenné kritérium: čas a zdroje - dostatočný rozpočet 48. Popíš process-oriented prístup k modelovaniu Ľudia sú len zdroje, procesy musia fungovať aj keď sa zmení tím, musia fungovať za všetkých okolností Podstatná je rola (analytik, programátor, tester), nie individualita Štandard pre komunikáciu je dokumentácia 49. Popíš people-oriented prístup Ľudia nefungujú vždy rovnako, dôraz na individualitu Dôležitá je kvalita členov tímu, nie ich počet Dôležitá je osobná komunikácia, podpora práce vývojového tímu 50. Popíš RAD - Rapid Application Development rýchly iteratívny vývoj prototypov funkčné verzie sú k dispozícii oveľa skôr ako u ostatných modelov intenzívne zapojenie zákazníka do vývoja - rýchle reakcie na zmeny Fázy: Plánovanie, Návrh, Prevedenie, Uzavretie a nasadenie Výhody - flexibilita, možná rýchla zmena požiadavky zákazníka, úspora čašu a zdrojov - môže viest k nižšej kvalite Nevýhody - nutnosť spolupráce so zákazníkom, nižšia kvalita návrhu, problém s udržovateľnosťou 51. Popíš RUP - Rational Unified Process objektovo orientovaná metodika venuje sa všetkým etapám vývoja SW (kto , čo , kedy, ako) Základne praktiky: využívanie existujúcich komponentov iteratívny vývoj model je vizualizovaný - UML priebežná kontrola kvality sprava požiadaviek zákazníka riadenie zmien systému výhody: vhodný pre veľkú škálu projektov, včasné odhalenie rizík, správa zmien, prepracovanie do detailov, UML nevýhody: u menších projektov neefektívny vývoj, komerčný(veľa podporných produktov) 4 fázy: inception/zahájenie - rozsah, náklady, riziká, prvý UC, 1-2 iterácie elaboration/projektovanie - plánovanie, špecifikácia požiadaviek, architektúra, analýza rizík, 2-4 iterácie construction/realizácia - analýza, návrh, implementácia, 2-4 iterácie transition/dodanie - dodanie, školenie, podpora pri zavedení, 2 iterácie (beta, plná verzia) 52. Popíš XP - extrémne programovanie Komunikácia, testovanie, párové programovanie Dôraz na spätnú väzbu - zákazník je člen tímu - vyhodnocuje dosiahnutú funkcionalitu Jednoduché veci je potrebné tvoriť jednoducho Uvoľňovať len malé zmeny postupne - ale často Testovanie je základ Proces vývoja - Skúmanie, Plánovanie, Iterácia, Produkcia, Údržba, Uzavretie 53. Popíš Scrum. Dôležitosť tímovej práce Skladá sa z: Pre-Game: Plánovanie - počiatočné požiadavky podľa priorít, analýza rizík, odhad času, zdrojov, formovanie tímu (5-10 členov), vedúci Scrum Master Architektonický návrh - tvorba doménových modelov, definícia architektúry systému Sprint: jedna iterácia, sprinty tvoria Development/implementáciu projektu, typická dĺžka iterácie je 30 dní Sprint Planning - stretnutie na začiatku Sprintu - vývojový tím, zákazníci, užívatelia Post-Game - integrácia výsledkov sprintov, testovanie systému, príprava dokumentácie, školenie užívateľov 54. Crystal Základné techniky zdieľa s XP (viac disciplíny), ale je menej produktívny ako XP (lepší akceptačný proces) Projekty rozdelené v kategórii podľa kritickosti, dôležitosti a veľkosti Kritickosť – aké sú straty, ak systém zlyhá - komfort, Discretionary (nepodstatné) money, Essentials (podstatné) money, život Väčší projekt potrebuje lepšiu metodiku a koordináciu, Kritickejší zase precíznejší prístup Metodiky sú priradené podľa veľkosti do kategórií označených farbami Silné stránky: iteratívne, časté nové verzie, ladenie procesu podľa spätnej väzby a počas vývoja, zapojenie užívateľa, priebežná integrácia Slabé stránky: Žiaden jasný spoločný proces, nevhodný pre vysoko kritické projekty, veľká závislosť na komunikácií 55. Čo je to abstrakcia? Zjednodušený pohľad na systém bez straty jeho významu 56. Čo je to zapuzdrenie? Súvisiace dáta, operácie a atribúty zoskupené do jednej jednotky za účelom zakrytia implementačných detailov 57. Čo je to dedičnosť? Definuje objekty a triedy na základe už existujúcich objektov, vzniká hierarchia 58. Čo je polymorfizmus? Znalosť triedy/objektu ako vykonať určitú operáciu, ktorá ale môže byť spoločná pre viac tried Diagramy 59. Popíš jazyk UML Unified Modelling Language Základný modelovací jazyk metodiky RUP Stavebné bloky UML: Predmety - prvky (trieda, prípad použitia, stav) Vzťahy - určujú vzájomnú súvislosť predmetov (závislosť, asociácia, agregácia, kompozícia, realizácia) Diagramy - modely UML (use case diagram, diagram tried, diagram zoskupení, diagram objektov) Ornamenty - obohacuje prvky (atribút, operácia) 60. Popíš jazyk OCL Object Constraint Language (OCL) Definuje obmedzenia, podmienky a pripomienky nad UML modelmi Formálny jazyk navrhnutý pre návrhárov Využitie: špecifikácia podmienok pre vykonanie metód špecifikácia obmedzení, hodnôt atribútov, tried 61. Popíš Diagramy jazyka UML 2.0 Diagramy štruktúry: D Tried, D objektov, D zoskupení Diagramy chovania: D prípadu použitia, Stavový D, D aktivít Diagramy interakcie: Sekvenčný D, D komunikácie 62. Popíš kardinalitu Maximálny počet vzťahov daného typu (vzťah. množina) v ktorých sa môže podieľať jedna entita (1..*, 0..*,..) 63. Popíš Vzťahy tried Dedičnosť - vzťah generalizácia medzi triedami, odvodená trieda zdieľa atribúty, chovanie, vzťahy, môže pridať atribúty, chovanie Asociácia - zachycuje vzťahy medzi triedami, asociácia má svoje násobnosti, názov, vyjadruje premenlivý vzťah medzi objektmi Agregácia - zoskupenie viacerých častí, zoskupený objekt môže existovať bez tvoriaceho objektu, konštitučný objekt môže byť súčasťou viacerých zoskupení Závislosť - vyjadruje vzťahy medzi objektmi, triedami Realizácia - vzťah medzi triedou a rozhraním 64. Popíš diagram tried (Class diagram) Zobrazuje triedy a statické vzťahy medzi nimi Okrem tried obsahuje rozhrania, zoskupenia a vzťahy (zobecnenie, asociácia, závislosť, realizácia) Je často používaný na modelovanie a návrh systému 65. Popíš diagram objektov (Object diagram) Zobrazuje objekty ako inštancie tried a ich vzťahy Sú úzko spojené s diagramami tried Popisuje statickú štruktúru systému v špecifickom čase Využívajú sa na testovanie presnosti diagramu tried Medzi objektmi existuje spojenie 66. Popíš diagram zoskupení (Package diagram) Ukazuje zoskupenia príbuzných elementov systému a závislosti medzi nimi Je užitočný na usporiadanie rozsiahlych systémov 67. Popíš diagram prípadov použitia (Use case diagram) Vytvára sa s pomocou užívateľov na zistenie funkčných požiadaviek na systém, hranice a rozsah systému Predstavuje súbor prípadov použitia (funkcia vykonávaná aktérom), aktérov (pracuje so systémom), vzájomných vzťahov, interakcií Každý prípad použitia popisuje postupnosť udalostí, má vstupné podmienky, tok udalostí a následné podmienky 67. Popíš stavový diagram (State diagram) Modelovanie dynamického chovania a zmien( stavy objektov, prechody medzi stavmi, počiatočný a koncový bod stavových zmien) Zachycuje stav jediného objektu Využíva sa na ujasnenie životného cyklu objektu Je nutnosťou pre vývoj systému 68. Popíš diagram aktivít (Activity diagram) Zvláštny prípad stavového diagramu, stavy predstavujú aktivity a prechody sú vyvolané dokončením aktivít Reprezentujú objektovo orientované vývojové diagramy Vhodný pre pochopenie toku činnosti (scenár prípadu použitia, detail operácie, algoritmu, obchodný proces) Je navrhnutý ako zjednodušený pohľad na dianie v priebehu procesu Podpora paralelného chovania - viacvláknové programovanie Nie je vhodný pre reprezentovanie zložitého vetvenia a popis chovania objektu v priebehu jeho života 69. Popíš sekvenčný diagram (Sequence diagram) Identifikuje základnú vnútornú dynamiku Popisuje spoluprácu skupiny objektov Ukazuje ako objekty medzi sebou komunikujú v časovej rovine Nie sú vhodne na zobrazenie detailu algoritmu Skladá sa z objektov a správ 70. Popíš diagram komunikácie (Communication diagram) Ukazuje účastníkov interakcie a dátové spojenia medzi nimi Vhodnejší pre zobrazenie spojení ako sekvenčný Sekvenčný je vhodnejší pri zobrazení sekvencie volaní 71. Popíš Data Flow Diagram (DFD) Diagram dátových tokov Technika pri štruktúrovanej analýze Je hierarchický model - ukazuje funkcie systému, toky medzi dátami, je doplnený minišpecifikáciami 72. Popíš Konceptuálne modely Doménový model - entity a pojmy problémovej domény (reprezentuje reálny systém (system-as-is), vychádzajú z nej obchodné, uživateľské, funkčné a nefunkčné požiadavky) Model architektúry - dekompozícia systému, napr.: diagram tried Modely chovania - uživateľské, funkčné požiadavky (málo aj nefunkčné), napr.: use case diagram, stavový diagram Modely interakcie - interakcie elementov (objekty, aktéri) v use case diagrame, napr.: diagram komunikácie Dátový model - perzistentné dáta (stále dáta), napr.: ERD Architektonické vzory 73. Popíš princípy objektovo orientovaného návrhu Single Responsibility Principle (SRP) - triedy by mali mať jedinú zodpovednosť, dôvod k zmene Open Closed Principle (OCP) - trieda by mala byt otvorená pre rozšírenie, uzavretá pre modifikácie Dependency Inversion Principle (DIP) - závislosť na abstraktnom, nie na konkrétnom, smer závislostí od konkrétneho k abstraktnému Acyclic Dependencies Principle (ADP) - závislosti medzi balíkmi nesmú tvoriť cykly Liskov Substitution Principle (LSP) - odvodené triedy by mali byt zameniteľné za bázové triedy (napr. kružnica - elipsa) Do not Repeat Yourself (DRY) - neopakujte rovnaký kód na rôznych miestach, vytvára všeobecnejšiu triedu 74. Popíš Návrh architektúry Zameriava sa na organizáciu systému - identifikujú sa komponenty, vzťahy a ich komunikácia Vytvorený na začiatku vývoja SW v prvej iterácii Návrh je spojený so špecifikáciou požiadaviek 75. Popíš Architektonické vzory Abstraktný popis dobrých odskúšaných praktík Sú overené na rôznych systémoch Obsahujú informácie o vhodnosti použitia, slabé a silné stránky Napr.: Model-View-Controller, Vrstvená architektúra, Klient-Server 76. Popíš Model-View-Controller Oddeľuje prezentáciu a interakciu od systémových dát (oddeľuje model a pohľad na model) Používa sa na rôzne zobrazenie a interakcie pre jeden model Výhody: dáta môžu byť menené nezávisle od reprezentácie a naopak Nevýhody: ťažšie spracovanie pre jednoduché modely Model - spravuje dáta a stav aplikácie, informuje View o zmenách stavu View - zobrazuje model, vyžaduje zmeny modelu, posiela užívateľské činnosti Controlleru Controller - zaisťuje zmeny modelu na základe akcií užívateľa a zmeny View na základe zmeny modelu Napr.: webová aplikácia, M - databáza, V - dynamické stránky, formulár, C - http protokol, validácia dát 77. Popíš Vrstvenú architektúru Rozdelenie systému do vrstiev - každá vrstva má svoju funkcionalitu, nadradená vrstva používa služby nižšej vrstvy (najnižšia vrstva = jadro systému), elementy každej vrstvy môžeme modifikovať nezávisle Výhody: náhrada vrstvy za novú vrstvu, redundantné služby (autentifikácia) Nevýhody: náročné oddelenie vrstiev, potreba priamej komunikácie vyššej a nižšej vrstvy, požiadavky na výkon aplikácie Podpora inkrementálneho vývoja - ľahšia úprava architektúry Napr.: knižničný systém riadiaci prístup k chráneným elektronickým zdrojom 78. Popíš Architektúru Klient-Server Funkcionalita je rozdelená do služieb - každá služba je poskytovaná nezávislým serverom Klient je užívateľ služieb, pristupuje na servery Použitie: prístupnosť pre veľký počet klientov, replikácia serverov pri zaťažení systému Výhody: distribúcia serverov v sieti, služby sú dostupné pre všetkých klientov Nevýhody: náchylnejšia na útoky (typ denial of service), výkon aplikácie nevieme predpokladať, problémy so správou serverov (vlastník 1 organizácia) Návrhové vzory 79. Popíš návrhové vzory Šablóna pre riešenie problému, nie jeho implementáciu Vzor popisuje problém a jadro jeho riešenia, riešenie je znovu použiteľné Obsahuje: názov, problém, riešenie a dôsledky Tvorivý vzor - zaoberá sa procesom tvorby objektu Štrukturálny vzor - zaoberá sa skladbou tried alebo objektov Chovanie - zaoberá sa spôsobom vzájomnej interakcie medzi objektami, triedami, spôsobmi, rozdelenie povinností medzi objekty alebo triedy 80. Jedináčik (singleton) Účel - trieda má jednu inštanciu Dôsledky - zdokonaľovanie operácií, zjednodušovanie zmien a návrhov, riadenie prístupu k jednej inštancií 81. Abstraktná továreň (Abstract Factory) Účel - vytvorenie príbuzných alebo závislých objektov bez špecifikácie konkrétnej triedy Dôsledky - izoluje konkrétne triedy, zjednodušuje výmenu produktových tried Nevýhoda: podpora nových produktových rád je náročná 82. Command Účel - zapuzdrenie požiadaviek alebo operácií, vzor chovania Dôsledky - jeden vykonávaný príkaz, uchováva stav klienta po vykonaní príkazu Zaslanie požiadaviek na obecnej úrovni, bez toho aby sme poznali konkrétny protokol 83. Observer Účel - definuje závislosť 1 ku N medzi objektami Dôsledky - klient nemusí poznať závislosť objektov Pri zmene stavu objektu sú informované všetky závislé objekty 84. Fasáda (Facade) Účel - zjednodušenie práce so zložitými požiadavkami a systémom, zjednodušenie komunikácie medzi prvkami Dôsledky - zjednodušenie rozhrania, možnosť výmeny vrstvy za fasádu bez zmeny užívateľských tried Jednoduché rozhranie, oddeľuje implementačné triedy a ich použitie Testovanie 85. Aký je rozdiel medzi validáciou a verifikáciou? Validácia - overenie, že SW splňuje potreby užívateľa Verifikácia - overenie, že SW vyhovuje špecifikácii 86. Popíš ciele a priebeh testovania Cieľom testovania je odhaliť chyby počas vývoja SW Test, ktorý neodhalí nesprávne chovanie SW je neúspešný Sú navrhnuté testovacie vstupy (dvojica vstupných a očakávaných výstupných dáta) Vstupné dáta sú zadané a výstupné dáta sú zaznamenané Výstupné dáta sa porovnajú s očakávanými Testovacie vstupy vyberáme také, u ktorých sa dá očakávať, že spôsobia chybu. 87. Funkčné testovanie – Black box Vychádza sa iba zo špecifikácie a neuvažuje sa vnútorná štruktúra programu Postup: využíva sa rozdelenie vstupov/výstupov do tried ekvivalencie každý vstup/výstup patrí práve do jednej triedy, pre ktoré je z určitého hľadiska chovanie systému identické (ak daný vstup hlási chybu, tak rovnaká chyba je aj pri druhom vstupe z rovnakej triedy) keď už sú vstupy rozdelené do tried, vyberie sa z každej triedy priemerná hodnota alebo medián, hranice triedy a niekoľko náhodných hodnôt 88. Štrukturálne testovanie – White box Návrh testovacích vstupov vychádza z vnútornej štruktúry programu, predpokladá sa dôkladná znalosť implementácie systému Keďže sa jedná o testovanie konkrétnej implementácie, snažíme sa pokryť rôzne štruktúry programu kritéria tak môžu byť založené na tokoch riadenia (pokrytie ciest v programe, rozhodovacích blokov, podmienok, príkazov) alebo na tokoch dát Postup: pre otestovanie úplnosti množiny testovacích vstupov sa používa mutačné testovanie keď je množina vstupov vybraná, spraví sa v programe úmyselne niekoľko chýb a spustí sa testovanie pomocou vybranej množiny podľa toho koľko týchto úmyselných chýb je zachytených sa dá odhadnúť úspešnosť testovania (koľko % chýb v software ostane neodhalených) Vysvetlenie postupu Black/White box na skúšku 89. Metriky - výpočty LOC- počet riadkov kódu kLOC - kilo LOC spoľahlivosť - stredná doba medzi výpadkami systému MTBF = MTTF+MTTR dostupnosť - pravdepodobnosť, že program v danom čase funguje (MTTF/MTBF)*100 MTBF - mean time between failures (MTTR + MTTF) MTTR - mean time to recovery (počet jednotiek offline/počet úsekov offline) MTTF - mean time to failure (počet jednotiek online/počet úsekov online) 90. Popíš Prístupy statického overovania Formálne (Inspection) Neformálne (Walkthrough) Pozeranie cez rameno (Over-The-Shoulder) Párové programovanie (Pair Programming) Kúpacia kačka (Rubber Duck Debugging) 91. Popíš Code Review. 200-400 LOC na prehliadku, odhalenie až 15 chýb za hodinu Najefektívnejší spôsob odhaľovania chýb v kóde, zvyšuje čitateľnosť, údržbu kódu, zlepšuje schopnosti menej skúsených programátorov 92. Popíš Stratégie/Techniky testovania. Funkcionálne testovanie - vstupy a výstupy na základe špecifikácie, metóda čiernej skrinky (black box, functional, closed box): zistenie či vstupné a výstupné dáta vyhovujú špecifikácii neberieme do úvahy vnútornú štruktúru, logiku modulu úplné funkcionálne testovanie je v praxi nemožné Štrukturálne testovanie - na základe vnút.štruktúry programu, metóda bielej skrinky (white box, open box): o vychádza z vnútornej štruktúry, testuje sa implementácia programu o pokrýva riadenie a údaje (dáta) - založené na tokoch riadenia a tokoch dát o mutačné testovanie - úmyselne zavedené chyby do programu  Náhodné testovanie - náhodné testovacie vstupy Testovanie rozhraní - na základe rozhraní medzi modulmi a špecifikáciou programu Testovanie zdola-nahor - testovanie komponentov na nižšej úrovni, potom na vyššej úrovni Testovanie zhora-nadol - testovanie modulov najvyššej úrovne, potom submoduly Sendvičové testovanie - kombinácia zhora-nadol, zdola-nahor, logická časť zhora-dolu, funkčná časť zdola-hore Jednofázové testovanie - testovanie modulov samostatne, potom sa naraz integrujú a otestujú, nevýhodou je zlá identifikácia miest chýb a náročné rozlíšenia jednej chyby od druhej Testovanie pozorovaním - viac verzií na testovanie (prototyp, technika programovania N- verzií, vývoj viacerých verzií na rôzne platformy), rovnaké výsledky -> verzia pravdepodobne funguje správne, nevýhodou sú rovnaké chyby vo verziách a nevyhovujúca špecifikácia 93. Popíš Statickú a Dynamickú analýzu Statická analýza - analýza programu bez spustenia, sústredí sa na časté programátorské chyby - syntaktické, neinicializácia premenných, delenie nulou, neoprávnený prístup do pamäti Dynamická analýza - analýza za behu testovaného programu, sústredí sa na nesprávnu prácu s pamäťou (Valgrind), uviaznutie (deadlock), časovo závislé chyby (race condition), hlási menej falošných chýb ako Statická 94. Popíš Akceptačné testovanie. Testovanie užívateľom na reálnych dátach, užívateľ rozhodne, či produkt splňuje zadanie, vzťahuje sa na zákaznícky softvér 95. Popíš Alfa a Beta testovanie. Alfa testovanie - tam kde sa vyvíja softvér, testovanie užívateľom (vývojári sledujú a evidujú chyby), známe prostredie Beta testovanie - testovanie užívateľom u seba, neznáme prostredie, výsledkom je správa užívateľa Ochrana intelektuálneho vlastníctva 96. Čo je to vlastníctvo? Neobmedzené právo na vec, vlastníctvo hmotných zdrojov je prirodzené pre ľudí, vlastníctvo nehmotných zdrojov je sporné - chýba im vzácnosť 97. Čo je to patent? Monopol na výrobok, službu, platí 20 rokov, je ho možné predať, súhlas na využitie sa dáva licenciou Aby bol patent uznaný ako vynález musí byť nový, výsledok vynález. činnosti, priemyslovo využiteľný, napr.: telefón, TV 98. Čo je to autorské právo? Výsledok tvorivej činnosti autora vyjadrené v akejkoľvek vnímateľnej podobe, autor je fyzická osoba, ktorá dielo vytvorila Vzniká vytvorením diela, sú chránené 70 rokov po smrti autora 99. Čo je to ochranná známka™? Slovné alebo obrazové označenie výrobku slovami, písmenami, číslami, farbou, kresbou Odlišuje výrobcu a propaguje, bráni tretím osobám používať rovnaké označenie (v ČR platí 10 rokov), Napr.: Microsoft Windows, Coca-Cola 100. Popíš licencie Slúži k udeleniu práv na využívanie intelektuálneho vlastníctva Proprietárne - privátne vlastnené a kontrolované, výrobca dodáva spustiteľnú aplikáciu, užívateľ nemá právo študovať či editovať zdrojový kód, Napr.: SW s licenciou na jednom počítači, licenčné programy pre školy, copyleft - udeľuje práva k modifikácii a redistribúcii pod určitými podmienkami; hlavná podmienka je, že Software bude naďalej slobodný – napr. GNU general public license BSD (Berkeley Software Distribution) - požaduje iba formálne atribúty modifikovaného softwaru, inak sa so softwarom dá voľne nakladať, napr. ho poskytovať v redistribúcii pod inou licenciou public domain - autor sa zrieka autorských práv, nemusí vždy spĺňať podmienky slobodného softwaru (napr. spustiteľný program bez zdrojového kódu) Programovacie jazyky 101. Popíš Generácie programovacích jazykov Prvá generácia - programovanie priamo v binárnom kóde Druhá generácia - assemblery, symbolické vyjadrenie binárnych inštrukcií (1 k 1) Tretia generácia - procedurálne jazyky, jeden príkaz transformovaný do 5-10 inštrukcií v bin.kóde Štvrtá generácia - neprocedurálne jazyky (čo treba vykonať, nie ako), jeden príkaz preložený do 30-50 inštrukcií v bin. kóde, tzv. užívateľské programovanie napr. Microsoft Excel 102. Popíš Typovanie a jazyky Význam - určiť sémantický význam elementov (poznáme príslušné operácie) Staticky typované jazyky - typová kontrola počas kompilácie napr.: C++, Java Dynamicky typované jazyky - typová kontrola počas behu programu napr.: Smalltalk, Self, Python, Lisp Silno typované - silné obmedzenia na kombináciu typov, zabránenie kompilácii kvôli nekompatibilným typom, tzv. typovo bezpečné (type safe) Slabo typované - slabé obmedzenia na kombináciu typov (napr.: implicitné pretypovanie) IT support Distribution. IT podpora používa multivendor strategy (stratégiu viacerých predajcov) skladá sa z vnútornej podpory 3 hlavní dodávatelia - IBM, ATOS, HP centrálny manažment spoľahlivosti, bezpečnosti, podpory aplikácií IT support sa skladá z IT Operations (operácie v danom prostredí s danou kvalitou a poplatkami, vybavovanie denných dotazov, menšie upgrady) a IT Transitions (prechody na naplnenie požiadaviek pre funkcionalitu, veľké upgrady, vylepšenia, projekty) Úlohy pre IT Operations Dostupnosť služieb, ochrana údajov, zálohovanie, legálne procesy (archivácia), podpora užívateľov, finančné ciele Úlohy pre IT Transitions Vylepšiť na novšie verzie, zmeniť poskytovateľa SW, nové štandardy Zmeniť stratégiu spoločnosti, reorganizácia spoločnosti, riadiť sa legálnymi požiadavkami (práva, dane, správy) Virtualization Výhody - flexibilita, lepšie využívanie zdrojov, pridelenie zdrojov je online, menej manuálnych činností v prípade HW modifikácie Nevýhody - prináša iný level komplexnosti, limit pripojenia - siete, vyššie požiadavky na stabilitu, licenčné limity pre aplikácie Cloud - špeciálny typ outsourcingu Public cloud: +flexibilita v pridelení zdrojov, +menej vlastnej snahy, -bezpečnosť, -poloha, -limitovaná záruka v prípade straty dát, -poplatky Private cloud: +bezpečnosť nie je problém, -vyššie poplatky, -menšia flexibilita 103. SLA (Service Level Agreement) Dojednaná dohoda medzi zákazníkom a poskytovateľom služieb o dostupnosti služieb a kvalite kvantifikovaným spôsobom. Väčšinou sa odkazuje na riešenie mimoriadnych udalostí, avšak môže zahŕňať kontinuitu podnikania, obnovu, riadenie výkonnosti, záruku, dostupnosť a ostatné parametre služieb. 104. OLA (Operational Level Agreement) Dohoda medzi internými podpornými skupinami, odvodený od SLA. Typicky je prísnejší než SLA a odráža iný druh procesu (dostupnosť služby vs. rozlíšenie času) 105. Popíš CMM. Capability Maturity Model - nástroje popisujúce, ako dobre sú nastavené praktiky, procesy a chovanie organizácie, zameranie na procesy Štruktúra modelu: úrovne zrelosti - 5 úrovní, najvyšší stupeň - ideálny stav kľúčové oblasti - súvisiace aktivity pre dosiahnutie cieľov ciele - definujú rozsah, obmedzenia, zámery kľúč. oblastí vlastnosti - praktiky začlenenia kľúčových oblastí do organizácie kľúčové praktiky - efektívne praktiky do začlenenia oblastí 106. Efektívnosť komunikácie. forma komunikace