├── img ├── 20230518144835.png ├── 20230523215135.png ├── 20230525111250.png ├── 20230525115631.png ├── 20230525184623.png ├── 20230525192847.png ├── 20230525195955.png ├── 20230525214112.png ├── 20230525221317.png ├── 20230525221638.png ├── 20230525224009.png ├── 20230526000518.png ├── 20230526101347.png ├── 20230526220652.png ├── 20230526220927.png ├── 20230530162603.png ├── 20230602104120.png ├── 20230602212700.png ├── 20230602212810.png ├── 20230602221810.png ├── 20230602223147.png ├── 20230602224136.png ├── 20230603105247.png ├── 20230603105928.png ├── 20230603110857.png ├── 20230603111248.png ├── 20230603112121.png ├── 20230603112705.png ├── 20230603121311.png ├── 20230603143753.png ├── 20230603144800.png ├── 20230603153352.png ├── 20230603154910.png ├── 20230603161229.png ├── 20230603163820.png ├── 20230604142455.png ├── 20230604142514.png ├── 20230604152821.png ├── 20230604183448.png ├── 20230604183525.png ├── 20230605121553.png ├── 20230605125209.png ├── 20230605125311.png ├── 20230605130130.png ├── 20230605132549.png ├── 20230605162806.png ├── 20230605165644.png ├── 20230605172409.png ├── 20230606160621.png ├── 20230606164944.png ├── 20230607122950.png ├── 20230607124347.png ├── 20230607124544.png ├── 20230607130528.png ├── 20230607130605.png ├── 20230608120112.png ├── 20230608120634.png ├── 20230608121047.png ├── 20230609000854.png ├── 20230609001314.png ├── 20230609001416.png ├── 20230610171630.png ├── 20230610173720.png ├── 20230611150321.png ├── 20230611150909.png ├── 20230611200016.png ├── 20230611214059.png ├── 20230611214616.png ├── 20230611215146.png ├── 20230611215253.png ├── 20230611215834.png ├── 20230611224121.png ├── 20230611224138.png ├── 20230611224805.png ├── 20230611224906.png ├── 20230611232516.png ├── 20230612104455.png ├── 20230612201616.png ├── 20230612205443.png ├── 20230613154105.png ├── 20230613181843.png └── 20230613181909.png ├── .github └── CONTRIBUTING ├── README.md ├── dev_4_uzivatelska_rozhrani.md ├── 7_distribuovane_systemy.md ├── 5_databaze.md ├── 3_softwarove_inzenyrstvi.md ├── 4_projektove_rizeni.md ├── dev_2_zpracovani_dat.md ├── 2_kvalita_kodu.md ├── 1_programovani_a_softwarovy_vyvoj.md ├── 6_pocitacove_site.md └── dev_1_analyza_a_navrh.md /img/20230518144835.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230518144835.png -------------------------------------------------------------------------------- /img/20230523215135.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230523215135.png -------------------------------------------------------------------------------- /img/20230525111250.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525111250.png -------------------------------------------------------------------------------- /img/20230525115631.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525115631.png -------------------------------------------------------------------------------- /img/20230525184623.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525184623.png -------------------------------------------------------------------------------- /img/20230525192847.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525192847.png -------------------------------------------------------------------------------- /img/20230525195955.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525195955.png -------------------------------------------------------------------------------- /img/20230525214112.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525214112.png -------------------------------------------------------------------------------- /img/20230525221317.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525221317.png -------------------------------------------------------------------------------- /img/20230525221638.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525221638.png -------------------------------------------------------------------------------- /img/20230525224009.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230525224009.png -------------------------------------------------------------------------------- /img/20230526000518.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230526000518.png -------------------------------------------------------------------------------- /img/20230526101347.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230526101347.png -------------------------------------------------------------------------------- /img/20230526220652.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230526220652.png -------------------------------------------------------------------------------- /img/20230526220927.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230526220927.png -------------------------------------------------------------------------------- /img/20230530162603.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230530162603.png -------------------------------------------------------------------------------- /img/20230602104120.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602104120.png -------------------------------------------------------------------------------- /img/20230602212700.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602212700.png -------------------------------------------------------------------------------- /img/20230602212810.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602212810.png -------------------------------------------------------------------------------- /img/20230602221810.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602221810.png -------------------------------------------------------------------------------- /img/20230602223147.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602223147.png -------------------------------------------------------------------------------- /img/20230602224136.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230602224136.png -------------------------------------------------------------------------------- /img/20230603105247.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603105247.png -------------------------------------------------------------------------------- /img/20230603105928.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603105928.png -------------------------------------------------------------------------------- /img/20230603110857.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603110857.png -------------------------------------------------------------------------------- /img/20230603111248.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603111248.png -------------------------------------------------------------------------------- /img/20230603112121.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603112121.png -------------------------------------------------------------------------------- /img/20230603112705.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603112705.png -------------------------------------------------------------------------------- /img/20230603121311.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603121311.png -------------------------------------------------------------------------------- /img/20230603143753.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603143753.png -------------------------------------------------------------------------------- /img/20230603144800.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603144800.png -------------------------------------------------------------------------------- /img/20230603153352.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603153352.png -------------------------------------------------------------------------------- /img/20230603154910.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603154910.png -------------------------------------------------------------------------------- /img/20230603161229.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603161229.png -------------------------------------------------------------------------------- /img/20230603163820.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230603163820.png -------------------------------------------------------------------------------- /img/20230604142455.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230604142455.png -------------------------------------------------------------------------------- /img/20230604142514.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230604142514.png -------------------------------------------------------------------------------- /img/20230604152821.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230604152821.png -------------------------------------------------------------------------------- /img/20230604183448.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230604183448.png -------------------------------------------------------------------------------- /img/20230604183525.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230604183525.png -------------------------------------------------------------------------------- /img/20230605121553.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605121553.png -------------------------------------------------------------------------------- /img/20230605125209.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605125209.png -------------------------------------------------------------------------------- /img/20230605125311.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605125311.png -------------------------------------------------------------------------------- /img/20230605130130.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605130130.png -------------------------------------------------------------------------------- /img/20230605132549.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605132549.png -------------------------------------------------------------------------------- /img/20230605162806.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605162806.png -------------------------------------------------------------------------------- /img/20230605165644.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605165644.png -------------------------------------------------------------------------------- /img/20230605172409.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230605172409.png -------------------------------------------------------------------------------- /img/20230606160621.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230606160621.png -------------------------------------------------------------------------------- /img/20230606164944.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230606164944.png -------------------------------------------------------------------------------- /img/20230607122950.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230607122950.png -------------------------------------------------------------------------------- /img/20230607124347.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230607124347.png -------------------------------------------------------------------------------- /img/20230607124544.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230607124544.png -------------------------------------------------------------------------------- /img/20230607130528.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230607130528.png -------------------------------------------------------------------------------- /img/20230607130605.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230607130605.png -------------------------------------------------------------------------------- /img/20230608120112.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230608120112.png -------------------------------------------------------------------------------- /img/20230608120634.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230608120634.png -------------------------------------------------------------------------------- /img/20230608121047.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230608121047.png -------------------------------------------------------------------------------- /img/20230609000854.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230609000854.png -------------------------------------------------------------------------------- /img/20230609001314.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230609001314.png -------------------------------------------------------------------------------- /img/20230609001416.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230609001416.png -------------------------------------------------------------------------------- /img/20230610171630.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230610171630.png -------------------------------------------------------------------------------- /img/20230610173720.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230610173720.png -------------------------------------------------------------------------------- /img/20230611150321.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611150321.png -------------------------------------------------------------------------------- /img/20230611150909.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611150909.png -------------------------------------------------------------------------------- /img/20230611200016.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611200016.png -------------------------------------------------------------------------------- /img/20230611214059.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611214059.png -------------------------------------------------------------------------------- /img/20230611214616.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611214616.png -------------------------------------------------------------------------------- /img/20230611215146.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611215146.png -------------------------------------------------------------------------------- /img/20230611215253.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611215253.png -------------------------------------------------------------------------------- /img/20230611215834.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611215834.png -------------------------------------------------------------------------------- /img/20230611224121.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611224121.png -------------------------------------------------------------------------------- /img/20230611224138.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611224138.png -------------------------------------------------------------------------------- /img/20230611224805.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611224805.png -------------------------------------------------------------------------------- /img/20230611224906.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611224906.png -------------------------------------------------------------------------------- /img/20230611232516.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230611232516.png -------------------------------------------------------------------------------- /img/20230612104455.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230612104455.png -------------------------------------------------------------------------------- /img/20230612201616.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230612201616.png -------------------------------------------------------------------------------- /img/20230612205443.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230612205443.png -------------------------------------------------------------------------------- /img/20230613154105.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230613154105.png -------------------------------------------------------------------------------- /img/20230613181843.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230613181843.png -------------------------------------------------------------------------------- /img/20230613181909.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/holubond/szmgr/HEAD/img/20230613181909.png -------------------------------------------------------------------------------- /.github/CONTRIBUTING: -------------------------------------------------------------------------------- 1 | Zkusme prosím dodržovat konvence v dokumentu, následovat styl jakým je psán společný základ a sekce DEV. 2 | 3 | Například: 4 | - části explicitně zmíněné v otázce (a případně sekce dodatečných poznámek) jsou uvedeny nadpisech druhé úrovně (`##`). 5 | - texty by měly být co nejvíc stručné, výstižné, straight to the point. Ukecanost nechme docům, toto by měl být materiál nabitý obsahem - formátem jde spíš o dokumentaci, než o knihu. 6 | - obecně známé věci nevysvětlujeme, akorát to ubírá přehlednosti dokumentu. Pokud je koncept vysvětlen v jiné sekci, hodíme [odkaz](). 7 | - klíčové je, aby se v dokumentu dalo dobře hledat a dobře se četl 8 | - pokud rozebíráme body nějakého textu, použijeme odrážky. Je tak jasné, že se daný blok vztahuje k předešlému textu. Musí být jasná hierarchie bloků textu, kromě odrážek je fajn si hrát i s odsazením. 9 | - každá odrážka by měla být nezávislá na ostatních odrážkách stejné úrovně 10 | - v případě potřeby uděláme hierarchii odrážek 11 | - je fajn se vyhýbat velkým jednolitým blokům textu, takové se špatně čtou a ještě hůř se v nich něco hledá. Důležité části můžeme třeba **zvýraznit**, zvlášť důležité části (třeba definice) dáme samostatně. 12 | - dodržujeme [markdown best practices](https://www.markdownguide.org/basic-syntax/) 13 | - vyvarujeme se slangu a anglikanismům, to komise nemá ráda 14 | - dokument by měl být relativně obecný, agnostický k technologiím, bez přílišného rozebírání specifik jednotlivých technologií (každý čtenář se specializuje na jiný stack, takže pro většinu budou detaily irelevantní). Výjimkou jsou konkrétní příklady technologií, ty zkusme držet na nutném minimu. 15 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Otázky SZMGR-SWE (DEV) 2 | 3 | Oficiální link s otázkami: [https://www.fi.muni.cz/studies/fe-mgr/swe2021.html](https://www.fi.muni.cz/studies/fe-mgr/swe2021.html) 4 | 5 | Za správnost/aktuálnost neručím, jako příklady jsem používal technologie mně blízké. Občas jsou v materiálech informace navíc (z jiných předmětů/zdrojů). Pokud najdete chybu/nepřesnost, feel free to PR. Občas míchám pojmy jako struktura a třída, myslím tím v podstatě to samé (rust/go struktury víceméně odpovídají java/c# třídám). Odkazy na zdroje v ISu vám nemusí fungovat, pokud jste v daném období předmět neměli... v takovém případě by mělo stačit přepsat období v linku. 6 | 7 | Sepsáno na základě přednášek, osobních zkušeností, praxe, a samozřejmě drobné pomoci ChatGPT :) Pro rychlé pochopení základních konceptů dané technologie doporučuju mrknout na [Fireship](https://www.youtube.com/@Fireship) a jeho `in 100 seconds` videa. 8 | 9 | Materiály mi stačily k úspěšnému absolvování státnic (otázky na sítě a UI) v létě 2023. 10 | 11 | #### Hotové otázky 12 | 13 | *Mohou nastat drobné změny, ale nic markantního* 14 | 15 | - [Programování a softwarový vývoj](./1_programovani_a_softwarovy_vyvoj.md) 16 | - [Kvalita kódu](./2_kvalita_kodu.md) 17 | - [Softwarové inženýrství](./3_softwarove_inzenyrstvi.md) 18 | - [Projektové řízení](./4_projektove_rizeni.md) 19 | - [Databáze](./5_databaze.md) 20 | - [Počítačové sítě](./6_pocitacove_site.md) 21 | - [Distribuované systémy](./7_distribuovane_systemy.md) 22 | 23 | Specializace DEV 24 | - [Analýza a návrh systémů](./dev_1_analyza_a_navrh.md) 25 | - [Zpracování dat](./dev_2_zpracovani_dat.md) 26 | - [Bezpečný kód](./dev_3_bezpecny_kod.md) 27 | - [Uživatelská rozhraní](./dev_4_uzivatelska_rozhrani.md) 28 | 29 | #### Dodatečné materiály 30 | 31 | *Osobně jsem je nepoužíval, ale mohly by pomoct objasnit některé koncepty* 32 | 33 | - [Bakalářské státnice (gdoc)](https://drive.google.com/drive/u/0/folders/0Bzy-o_Kqmve_dkY1aW15WVVrYU0?resourcekey=0-IJZwAUN1lTX_XIo6przyUQ) - doporučeno [@thes01](https://github.com/thes01) 34 | 35 | 36 | Za korekce a doplnění díky [@xvanick1](https://github.com/xvanick1), [@thes01](https://github.com/thes01) a [vydrazde 37 | ](https://github.com/vydrazde)! 38 | -------------------------------------------------------------------------------- /dev_4_uzivatelska_rozhrani.md: -------------------------------------------------------------------------------- 1 | # Uživatelská rozhraní. 2 | 3 | > Uživatelská rozhraní. Principy návrhu a vývoje uživatelského rozhraní v moderních softwarových systémech, vč. webových, mobilních. Proces vývoje uživatelského rozhraní a zásady kvality. User experience (UX), interaction design, prototypování, wireframování, uživatelský výzkum, testování použitelnosti. Technologie a nástroje. Příklady z praxe pro vše výše uvedené. (PV182 || PV247 || PV278) 4 | 5 | *Fun fact: v PV247 se toho o této otázce (vyjma základů Reactu) moc nedozvíte. Ostatní předměty jsem neměl, tak jen z vlastních zkušeností* 6 | 7 | ## Principy návrhu a vývoje uživatelského rozhraní v moderních softwarových systémech, vč. webových, mobilních. 8 | 9 | Klíčem k úspěchu UI je uživatelská přívětivost a snadné použití rozhraní. Našlapaný systém s tunou pokročilých funkcionalit bude k ničemu, pokud se nedá jednoduše používat koncovými uživateli. Běžní uživatelé obvykle dokáží systémum s dobrým UI prominout i některé funkcionální nedostatky. 10 | 11 | Návrh rozhraní může ovlivňovat 12 | - jedná se i interní, nebo veřejný systém (musí s ním uživatelé pracovat, nebo s ním pracují jen když chtějí?) 13 | - úroveň odbornosti uživatelů 14 | - nutnost možnosti přizpůsobení 15 | - nutnost vícejazyčnosti aplikace (problém mohou dělat třeba odlišné druhy písma) 16 | - nutnost přístupnosti (accessibility) pro uživatele s nějakým omezením (zrakové či sluchové specifické potřeby, nutnost používat pro ovládání pouze myš/pouze klávesnici) 17 | - platforma 18 | 19 | UI se obvykle vyvíjí jako monolit, ale je možné dělat i microfrontendy. 20 | 21 | Je fajn brát v potaz 22 | - uživatelskou přívětivost (složité formuláře je fajn dělit na vícero částí, mít pole top-down (ne tabulka polí)) 23 | - bezpečnost - pro aplikace, na které mohou cílit útočníci je fajn stránku uživateli přizpůsobit, třeba jeho fotkou, aby bylo těžké stránku napodobit 24 | - skrývání hesel 25 | - používání vhodných input polí 26 | - rozhraní by mělo být jednotné 27 | - responsivity - fungování aplikace na různě velkých obrazovkách 28 | 29 | V současnosti je nejuniverzálnějším způsobem tvorby UI HTML+CSS+JS. Aktuálně jsou populární frontend js frameworky (React, Vue, Solid, Svelte, Angular..). Lze je použít v prohlížeči, jako desktopovou aplikaci (Electron - přibalí se k aplikaci chromium, nebo s využitím native webview třeba Tauri), pro mobilní aplikace (Progressive Web App, není nutné instalovat z appstore), případně mají vlastní verze nativní mobilním zařízení (React Native, Svelte Native...). Tyto technologie mají obvykle dobře řešené věci jako accessibility či lokalizace, existují pro ně solidní komponentové knihovny. 30 | 31 | Aktuálním trendem se zajímavým potenciálem je WebAssembly, které umožňuje použití kompilovaného jazyka. Výsledná aplikace je spustitelná v prohlížeči a z pravidla rychlejší, než JS. WASM podporuje 2 mody - práci s DOM, nebo přímé vykreslování na canvas (používá třeba Figma). 32 | 33 | Alternativou může být použití multiplafrormního frameworku Flutter (používá jazyk Dart, podporuje android, ios, web), který umožňuje vývoj pro vícero platform z jednoho zařízení. 34 | 35 | Nativními jazyky pro mobilní aplikace jsou swift (ios) a java/kotlin (android). 36 | 37 | Pro desktopové aplikace je možné použít i technologie jako GTK (existují bindingy na různé jazyky) nebo Qt (C++), JavaFx... 38 | 39 | **Specifika pro web** 40 | - řešíme, kdy je stránka renderovaná 41 | - Server side rendering - plně renderovaná na serveru, vhodné pro statické aplikace 42 | - Client side rendering - renderovaná na straně klienta, data jsou do aplikace přidaná (pomocí dotazů na server) 43 | 44 | - Tradičně aplikace fungovaly multi-page (přechod na stránku znamenal kompletně nový page load (e.g. PHP)) 45 | - Později se přešlo na single-page přístup pomocí client side rendering 46 | - aktuálně je možné přístupy míchat (initial page load je SSR, následně CSR), což je fajn pro iniciální page load, friendly pro SEO roboty... (e.g. nextjs) 47 | 48 | ## Proces vývoje uživatelského rozhraní a zásady kvality. 49 | 50 | Začneme uživatelským výzkumem, abychom pochopili skutečné požadavky na UI. Následuje návrh pomocí wireframů a prototypů, které můžeme použít pro zpětnou vazbu a jako předlohu pro vývojovou práci. Na konec je důležité provést uživatelské testování s různými typy uživatelů, abychom předešli problémům při nasazení aplikace. 51 | 52 | ### Uživatelský výzkum, analýza 53 | - Je důležité určit, kdo jsou naši uživatelé, jak dosud pracují se stávajícími systémy, co jim vyhovuje a co ne... 54 | - Je důležité určit, co jsou požadavky na systém, jak se používá (můžeme se snažit o minimalizaci kliknutí pro dosažení operace...) 55 | - s uživateli lze řešit i náš produkt ve **focus groups** 56 | - lze použít A/B testování - každé skupině uživatelů prezentujeme určitou variantu produktu a sledujeme vliv 57 | 58 | ### Interaction design 59 | 60 | Snažíme se pochopit, jakým způsobem uživatelé se systémem pracují či interagují a uzpůsobit tomu uživatelské rozhraní. 61 | 62 | ### Wireframování 63 | 64 | Vhodné pro návrh rozložení jednotlivých komponentů rozhraní, neřešíme barvy/styly, ale jen layout a hrubé rozložení obsahu. 65 | 66 | ### Prototypování 67 | 68 | Pomocí návrhových nástrojů jako AdobeXD nebo Figma, lze vytvořit (z části i interaktnvní) prototyp, který lze použít pro prvotní uživatelské testování. 69 | 70 | ## User experience (UX) 71 | 72 | Je kombinací aspektů uživatelského rozhraní 73 | - vizuální krása 74 | - použitelnost (umožňuje fungovat i s omezeními) 75 | - užitnost (umožňuje provádět chtěné akce) 76 | - efektivita (usnadňuje provádění akcí), e.g. 77 | - uživatel by neměl být nucen do systému zadávat totožnou informaci vícekrát 78 | - pro časté akce je fajn umožnit použití dobře známých klávesových zkratek 79 | 80 | Celkové user experience určuje, zda uživatelé budou chtít náš produkt používat. 81 | 82 | ## Testování použitelnosti 83 | 84 | Může zahrnovat 85 | - pozorování uživatelů při provádění úkonů v rámci systému 86 | - sledujeme jejich akce, reakce, potíže 87 | - na základě sledování lze navrhnout řešení 88 | - evaluace experty z oblastí přístupnosti (accessability), lze také použít automatizované nástroje jako Lighthouse 89 | - sledování očí uživatele při používání produktu, zjistíme tak, jaké části rozhraní nejvíce upoutají pozornost uživatelů, je k tomu potřeba souhlas uživatele 90 | -------------------------------------------------------------------------------- /7_distribuovane_systemy.md: -------------------------------------------------------------------------------- 1 | # Distribuované systémy 2 | > Základní pojmy, principy. Rozdíl mezi centralizovanou a distribuovanou architekturou systému, nevýhody obojího a jejich překonávání. Replikace, sdílení dat. Architektura orientovaná na služby (SOA), webové služby. Příklady existujících technologií a jejich využití. Příklady z praxe pro vše výše uvedené. ([PA053](https://is.muni.cz/auth/el/fi/jaro2023/PA053/um/)) 3 | 4 | ## Základní pojmy, principy 5 | 6 | **Distribuovaný systém** se skládá z komponentů (počítačů) propojených komunikační sítí. Distribuované systémy řeší problémy (výpočty/zpracovávání requestů) spoluprací jednotlivých komponentů (každý dělá něco). Díky tomu se systém snadněji škáluje (posilujeme subsystém, který má problémy). 7 | 8 | Architektury popsány v [otázce 1](./1_programovani_a_softwarovy_vyvoj.md#základní-koncepty-softwarových-architektur-z-pohledu-implementace-vícevrstvá-architektura-moderních-informačních-systémů-architektura-model-view-controller), takže jen shrnutí 9 | 10 | **Monolitická architektura** - obsahuje vše, co systém potřebuje, je možné pouze vertikální škálování, špatná spolehlivost (pád znamená pád celého systému) 11 | 12 | **Úrovňová (tiered) architektura** (nezaměňovat s layered) - jednotlivé úrovně lze distribuovat, paralelizovat, nahradit (komunikace skrz API) 13 | - Klient může být tenký/tlustý dle poskytnuté funkcionality, klasické úrovně bývají klient, server, databáze. 14 | 15 | **Hexagonal/Microkernel/component-based** - základní aplikace poskytuje minimální funkcionalitu, zbytek se dodává skrz plug-in komponenty komunikující přes předdefinované api. Komponenty je možné případně zapojovat za běhu systému. Další možnost využití komponentů - pokud potřebujeme používat legacy systém, který si nemůžeme dovolit přepsat, je možné ho zabalit jako komponent a přistupovat k němu přes naše kompatibilní rozhraní. Vývoj komponentových systémů je náročnější (zvlášť problematické je správně určit rozhraní), ale umožňuje větší přizpůsobitelnost/znovupoužitelnost komponentů v budoucích projektech. E.g. extensions ve VSCode, component-based architekturu používá Jakarta Enterprise Edition, kde jednotlivé Java Beans jsou komponenty 16 | 17 | **Pipeline architecture** - sekvenční zpracování, každý komponent se stará o relativně transformaci vstupu na výstup (dělej malou věc, ale dělej ji dobře) 18 | 19 | **Service-oriented architecture** - popsáno v [samostatné kapitole](./7_distribuovane_systemy.md#architektura-orientovaná-na-služby-soa) 20 | 21 | **Microservice architecture** - vysoká koheze, nízká provázanost služeb, systém je tvořen velkým množstvím malých služeb. Důležitá je rychlá komunikace mezi službami (gRPC). Služby nesdílí DB. 22 | 23 | **Remote Procedure Call** umožňuje spuštění předem vystavené procedury mezi procesy (i na vzdáleném stroji) tak, jako bychom proceduru volali přímo v kódu. Implementace procedury může být v odlišném programovacím jazyce. Součástí je definice rozhraní, ze kterého je možné vygenerovat odpovídající volatelné funkce/struktury použité pro argumenty pro náš jazyk. De-facto standardem je dnes gRPC. Pro fullstack typescript aplikace je dnes populární používat tRPC. V PA053 se probírala CORBA (primární focus na Javu, ale podporovala i jiné jazyky, nejde jen o RPC, ale o architekturu pro komunikaci mezi objekty v distribuovaném prostředí), ale ta se v nových systémech prakticky nepoužívá kvůli složitosti/lepším alternativám, nahrazena jednodušším SOAP a REST, nebo RPC řešeními (gRPC, funguje na HTTP/2, zprávy binárně serializuje pomocí protocol bufferu). 24 | 25 | Pro komunikaci se v distribuovaných systémech kromě RPC používají **message queues** a **event brokers**, kteří umožňují komunikaci typu publisher-subscriber, nebo zpracování jedním z množiny příjemců, a jsou schopny zprávy persistentně uchovávat (hodí se pro transakční zpracování, spolehlivost v případě výpadku). Obecně lze rozlišovat mezi zprávamy určenými do **queue** (klasická fronta, očekáváme zpracování jedním konzumentem) a **topic** (zpráva jde všem poslouchajícím). E.g. [Apache Kafka](https://www.youtube.com/watch?v=uvb00oaa3k8), [RabbitMQ](https://www.youtube.com/watch?v=NQ3fZtyXji0). 26 | 27 | Alternativně se může pro komunikaci v distribuovaném systému používat e.g. REST, nebo (pokud chceme low level kontrolu a výkon) přímá komunikace mezi sockety. 28 | 29 | **Cloud** - výhodou je, že můžeme používat platformu/infrastrukturu jako službu, aniž bychom se o ni museli starat/provádět nákladnou iniciální investici. Výpočetní výkon lze (i automaticky) upravit/škálovat na základě aktuálního vytížení. Fyzické zdroje mohou být sdílené, čímž je možné dosáhnout nižší ceny a je možné distribuovat výpočetní požadavky (peaky různých aplikacích v různých dobách zvládne i jeden stroj). Datová centra lze volit na základě blízkosti k našim zákazníkům. 30 | 31 | **GRID computing** - výpočet velmi náročných úloh pomocí velkého množství zdrojů (např. dobrovolnický Folding@home). Zdroj může být CPU, storage, speciální zařízení, ... 32 | 33 | **Batch vs Stream processing** 34 | ![](img/20230602104120.png) 35 | 36 | U batch processingu můžeme distribuovat pomocí jednotlivých jobs, řeší se plánování jobs (může stačit obyčejná fronta) 37 | 38 | Stream e.g. Apache Kafka 39 | 40 | **MapReduce** - k transformaci dat používáme operace MAP (transformace dat 1:1) a REDUCE (sumarizace dat N:1). MAPery lze triviálně paralelizovat (stejné i rozdílné operace), u REDUCErů je to trochu složitější, paralelizujeme rozdílné operace. E.g. Apache Hadoop 41 | 42 | 43 | ## Rozdíl mezi centralizovanou a distribuovanou architekturou systému, nevýhody obojího a jejich překonávání 44 | 45 | Hlavním rozdílem je, že centralizovaná architektura shromažďuje data a logiku na jednom místě, distribuovaná architektura rozptyluje logiku do více samostatných komponentů (běžících třeba i na samostatných strojích), které spolu komunikují. 46 | 47 | Nevýhody centralizované architektury 48 | - neumožňuje horizontální škálování => škálujeme vertikálně 49 | - selhání části znamená selhání celku => redundance, záložní servery 50 | - nízká flexibilita, vysoká provázanost => důraz na kvalitu kódu 51 | 52 | Nevýhody distribuované architektury 53 | - komplexita celkového systému, náročnější správa 54 | - vyžadují více/složitější komunikaci, složitější synchronizace, náchylnost na latenci => použití message queues, gRPC, eventual consistency 55 | 56 | 57 | Oproti centralizované architektuře distribuované systémy 58 | - nebývají požadavky/transakce ACID, ale BASE 59 | - **BAsically available** - nefunkčnost části nezpůsobí nefunkčnost celku, zbytek funguje i v případě nefunkční části systému. e.g. na netflixu nemusí fungovat služba hledání, ale vše ostatní běží v cajku. Na každý dotaz dostaneme nějakou odpověď. 60 | - **Soft state** - změny v systému mohou nastávat i když nepřichází žádné dotazy - systém takto propaguje data, aby dosáhl konzistence 61 | - **Eventually consistent** - data nemusí být konzistentní okamžitě po získání odpovědi na dotaz, ale až po nějaké chvíli 62 | - selhání (pád) části systému neznamená pád celku 63 | - jsou flexibilnější na modifikace díky nízké provázanosti 64 | 65 | ## Replikace, sdílení dat 66 | 67 | V distribuovaných systémech se používá replikace dat z různých důvodů. U distribuovaných databází(Apache Cassandra)/filesystémů (Apache Hadoop) to může být z důvodu bezpečnosti/dostupnosti/prevence výpadku, obecně se tím ale v systémech snažíme zajistit rychlejší odezvy. Centrální databáze, ve které se sdílí data, se může stát limitujícím bodem -> použijeme buď distribuovanou databázi, která replikaci řeší interně, nebo vícero databází, které mohou být jednodušší (MongoDB), protože se distribucí dat vzdáváme ACID a fungujeme s BASE. Určitá replikace dat vzniká kešováním (Redis). U replikace je potřeba nějakým způsobem řešit invalidaci dat po změně (timeout, nebo CQRS). 68 | 69 | Replikace je kýžená u content delivery network (CDN), kde se snažíme mít statické zdroje (web, obrázky) co nejblíže uživateli, aby se dosáhlo rychlého načítání. 70 | 71 | NoSQL databáze mají obvykle mechanismy pro automatickou replikaci/distribuci dat mezi různými uzly. Je možné použít sharding (rozbijeme data, uzel se stará o svou doménu) pro distribuci dat, a/nebo master-slave replikaci pro škálování (u aplikací s častým čtením) a prevenci výpadků (spadne master? jeden ze slaves je nový master) - master se při zápisu stará o aktualizaci dat na slaves. 72 | 73 | Pro sdílení dat (událostí) je možné použít Apache Kafka, platformu pro streamování dat ukládaných do logů. Pro sdílení informací o službách distribuovaného systému se dá použít Apache ZooKeeper. 74 | 75 | 76 | ## Architektura orientovaná na služby (SOA) 77 | 78 | Hybrid mezi microservices a monolitem, poměrně pragmatická architektura pro škálovatelný systém. Systém je tvořen vzájemně nezávislými, samostatně nasaditelnými a vzájemně komunikujícími službami (obvykle 4-12), které obsahují ucelené jednotky funkcionality (e.g. uživatelé, správa produktů, správa objednávek, platební služba, mailová služba...). Každá služba může být nezávisle na ostatních škálována. Nad službami může být pro zajištění jednotného API vrstva fasády. Služby obvykle sdílí databázi, ale je možné ji rozbít na vícero nezávislých celků. Je náročnější na vývoj, ale celkově je systém díky modularizaci lépe udržitelný a škálovatelný. 79 | 80 | ## Webové služby 81 | 82 | Komponenty umožňující komunikaci a interakci prostřednictvím standardizovaných protokolů a formátů. Jsou založeny na Service Oriented Architecture. Web services poskytují abstrakci funkcionalitě služby skrz webové API. Skrz definiční jazyk je formálně popsáno schéma/rozhraní dané služby a je možné generování klientského kódu pro různé programovací jazyky s cílem usnadnit použití webové služby. Schéma může být zároveň generováno přímo ze zdrojového kódu prostřednictvím anotací. 83 | 84 | Dříve se používaly web services založené na **SOAP** (simple object access protocol) a **XML**, definované pomocí **Web Service Definition Language (WSDL)**. 85 | 86 | Aktuálně se pro tyto účely spíše používá **REST** (representational state transfer, není to protokol, ale architektonický styl pro definici rozhraní) a **JSON** (byť je možné použít i jiné formáty), definované pomocí **OpenAPI Specification**, případně **GraphQL** (a JSON) se svým **GraphQL Schema** a dotazovacím jazykem. GraphQL používá jeden entrypoint (+1 playground) a umožňuje přesně specifikovat kýžená data (až na úroveň polí) a řešit tak problém s overfetching (1 dotaz obsahuje zbytečná data) a underfetching (v dotazu nemáme dostatek dat, takže děláme vícero různých dotazů). 87 | 88 | *SOAP je nezávislý na transportu, REST využívá HTTP. REST je jednodušší, rychlejší a efektivnější. SOAP umožňuje jednu zprávu cílit více příjemcům, přechod zprávy přes prostředníky, kteří mohou zpracovávat hlavičku (tělo je určeno jen příjemci). SOAP umožňuje výměnu strukturovaných a typovaných XML dat SOAP hlavička (nepovinná) může obsahovat metadata, QoS, bezpečnostní informace, SAML data, session identifikátor (a.k.a. cookie)..., SOAP obálka je root XML prvek zprávy, obsahuje namespace (určunící verzi protokolu), styl kódování dat, SOAP tělo obsahuje samotný obsah zprávy. REST umožňuje provázanost (díky hyperlinkům) a je možné se pomocí něj dostat na úplně jinou stránku mimo náš systém.* 89 | 90 | *REST se dívá na web jako na zdroje adresovatelné URL, které vrací reprezentaci dat (HTML, XML, PNG, JSON...). Příjem dat uvede klienta do stavu, který může být transformován přístupem na jiný zdroj. Je bezstavový, každá zpráva obsahuje vše, co je nutné pro její interpretaci (správně by zpráva neměla obsahovat cookie, ale třeba JWT), dotazy jsou kešovatelné.* 91 | 92 | ## Notes 93 | 94 | **Middleware** - vrstva softwaru poskytující rozhraní pro interakci s různými službami/systémy, abstrakce k často používané funkcionalitě, případně vrstva propojující existující systémy. 95 | - e.g. CORBA, Web Services, REST, message queue systémy, event brokeři. 96 | -------------------------------------------------------------------------------- /5_databaze.md: -------------------------------------------------------------------------------- 1 | # Databáze 2 | > Principy ukládání dat, databáze a souborové systémy. Kódování a komprese dat. Architektura relačních databází, dotazovací jazyk SQL a jeho části (definice, manipulace, transakce). Jazyk definice datového schématu, DDL. Jazyk manipulace s daty, DML. Relační algebra, integritní omezení, řízení transakcí. Indexování, hašování. Příklady z praxe pro vše výše uvedené. ([PV003](https://is.muni.cz/auth/el/fi/jaro2022/PV003/um/) || PV062) 3 | 4 | ## Principy ukládání dat, databáze a souborové systémy 5 | 6 | Data se v praxi ukládají přímo do souborového systému, nebo do databáze (relační, dokumentové, grafové...). 7 | 8 | ### Souborový systém 9 | - menší systémové nároky, jednodušší 10 | - náročné zajištění konzistence, nutnost řešení zamykání souborů, problematický transakční přístup 11 | - náročnější správa přístupových práv 12 | - nutnost konzistentně řešit formát dat 13 | - horší čitelnost & dokumentovatelnost datového modelu 14 | - operační systém slouží jako abstrakce pro aplikace, umožňuje jednotný přístup k různým souborovým systémům 15 | 16 | - pro aplikace se hodí na ukládání velkých souborů (pdf, obrázky, video, statická stránka, pokud tedy nepoužijeme CDN), které je nepraktické uchovávat v databázi. Je nutné dávat pozor, abychom neposkytli přístup jinam než chceme. 17 | 18 | ### Databázový systém 19 | - nezávislý na aplikaci, jednotné rozhraní pro všechny 20 | - snadné zabezpečení, konzistence, souběžný přístup 21 | - snadná čitelnost, dokumentovatelnost 22 | - relační systémy korelují s ERD 23 | - deklarativní přístup 24 | - optížná implementace složitějších struktur (záleží však na systému) 25 | - O relačních databázích platí, že umožňují ACID [transakce](./5_databaze.md#řízení-transakcí). 26 | 27 | ## Kódování a komprese dat 28 | 29 | Techniky s cílem transformace informací do formátu, který je efektivní na ukládání či přenos. 30 | 31 | **Bezztrátová komprese** - z komprimovaných dat jsme schopni plně rekonstruovat původní data (e.g. png, zip) 32 | **Ztrátová komprese** - část komprimovaných dat je ztracena (e.g. jpeg, mp3), ale jsme schopni dosáhnout větší komprese 33 | 34 | ### Vybrané metody 35 | 36 | **Statistické** 37 | - [Huffmanovo kódování](https://www.youtube.com/watch?v=iEm1NRyEe5c) - na základě frekvence určíme pro každý symbol kódovací znak, kód má minimální redundanci, proměnlivá délka kódu symbolů 38 | 1. seřadíme znaky podle frekvence do prioritní fronty ve formě uzlů, u každého máme uvedenou frekvenci 39 | 2. vyjmeme 2 uzly s nejmenšími frekvencemi a spojíme je do uzlu, který bude mít frekvenci rovnou součtu frekvencí. Takto vytváříme stromovou strukturu. Opakujeme, dokud nemáme 1. 40 | 3. procházíme stromovou strukturu od kořene, levé větve značíme `0`, pravé `1`, cesta od kořene po uzel unikátně identifikuje symbol a kombinací `0` a `1` získáme kód pro daný symbol 41 | 42 | - [Shannon-Fano](https://www.youtube.com/watch?v=dJCck1OgsIA) - podobný jako Huffman, nemusí být optimální, ale jdeme od kořene a sekvenci symbolů seřazených dle frekvence dělíme na poloviny (+-, sčítáme frekvence a při překročení poloviny dělíme), Při každém dělení značíme `0` a `1`. Jakmile je ve vytvořené polovině jen 1 symbol, už není co dělit. 43 | 44 | 45 | 46 | ## Architektura relačních databází 47 | 48 | *Fun fact: Jaká architektura se v RDBMS používá? To se v předmětu `Architektura relačních databází` nedozvíte* 49 | 50 | Nějaká jednoduchá architektura by mohla vypadat takto: 51 | - databázový server 52 | - přijímá, zpracovává a odpovídá na požadavky 53 | - relační databázový systém 54 | - autentizace, autorizace 55 | - aplikace pracující nad samotnou databází 56 | - umožňuje tvorbu tabulek/indexů... manipulaci s daty, jejich čtení... 57 | - zajišťuje integritu dat 58 | - vyhodnocuje a zpracovává SQL queries, provádí vnitřní optimalizace 59 | - může dělat kešování 60 | - databáze - samotné místo, kde jsou data uložena 61 | 62 | RDBMS může obsahovat techniky pro administraci přístupových práv (omezení určitých operací, viditelnost dat až na row/column level...). 63 | 64 | Pokud se otázkou myslí *Z jakých prvků se relační databáze skládají*, pak by bylo fajn mluvit o tabulkách, sloupcích, jazyku SQL pro jejich definici (DDL, data definition language) a manipulaci (DML, data manipulation language), indexech, (materializovaných) views... 65 | 66 | ## Dotazovací jazyk SQL a jeho části (definice, manipulace, transakce) 67 | Dotazovací jazyk SQL vychází z [relační algebry](./5_databaze.md#relační-algebra). 68 | 69 | Obsahuje konstrukty pro definici datového schématu, pro manipulaci s daty a pro transakční zpracování (viz další sekce). 70 | 71 | V některých systémech má prostředky pro procedurální programování, PL/SQL (třeba Oracle). 72 | 73 | SQL může obsahovat triggery, tedy dodatečné akce, které se mají vykonat při určitém příkazu (INSERT, UPDATE, DELETE). Používají se třeba pro udržování history table, nebo pro aktualizaci `updated_at`, pokud to nepodporuje daný RDBMS. 74 | 75 | Při práci s SQL používáme prepared stetements, abychom zabránili SQL injection. 76 | 77 | ## Jazyk definice datového schématu, DDL. 78 | 79 | *Note: různé RDBMS podporují různé typy. Třeba TEXT v základu SQL definován není, ale v praxi je použití VARCHAR2 s fixní délkou příliš nepraktické, proto ho tu uvádím* 80 | 81 | Tvorba tabulky 82 | 83 | ```sql 84 | /* Blokový koment */ 85 | -- Inline koment 86 | CREATE TABLE Products ( 87 | id INT PRIMARY KEY, --třeba u pg je možné použít SERIAL, abychom si nemuseli dělat sekvence 88 | cost INT NOT NULL, 89 | ean INT UNIQUE NOT NULL, 90 | name TEXT NOT NULL, 91 | description TEXT, 92 | created_by INT NOT NULL REFERENCES User(id) 93 | updated_at DATETIME, 94 | ); 95 | ``` 96 | 97 | V praxi je lepší si generovat vždycky primární klíče - externí unikátní hodnoty nemusí být vždy zas tak unikátní/neměnné. Je lepší používat čísla, než stringy (stačí jedna operace porovnání => rychlejší, zvlášť, když jde o PK). Compound primary key je možný, ale opět bývá pomalejší. 98 | 99 | Pro generování dalších hodnot ID se dřív používaly sekvence, dneska stačí hodit `SERIAL`, nebo `AUTOINCREMENT`. 100 | 101 | Pro datum/čas používáme DATETIME. Pokud bychom použili INTy & unix timestamp, v roce 2038 bychom měli problém. 102 | 103 | U cizích klíčů můžeme specifikovat `ON DELETE` `CASCADE` (se smazáním uživatele se smažou i jím přidané produkty), `SET NULL` (se smazáním uživatele se nastaví `created_by` na NULL, což ale kvůli našemu constraintu nepůjde). V aktuální konstelaci daného uživatele nemůžeme smazat. 104 | 105 | Modifikace tabulky 106 | - přidání sloupce, odebrání sloupce, zahození tabulky (selže, pokud na ni jsou reference z jiných tabulek) 107 | ```sql 108 | ALTER TABLE Products ADD picture TEXT; 109 | ALTER TABLE Products DROP COLUMN description; 110 | DROP TABLE Products; 111 | ``` 112 | 113 | Je možné použít `IF EXISTS` a `IF NOT EXISTS`, aby nám skript nepadal při opakovaných createch/dropech, ale to se hodí hlavně pro hraní si. 114 | 115 | V produkci použijeme migrační schéma obsahující UP a DOWN skripty, abychom mohli případně akce revertovat. 116 | 117 | ## Jazyk manipulace s daty, DML. 118 | 119 | **Insert** 120 | 121 | ```sql 122 | INSERT INTO Tabulka(sloupec_a, sloupec_b) 123 | VALUES (hodnota_a, hodnota_b); 124 | ``` 125 | 126 | Kontrolují se integritní omezení, v případě autoincrement/serial klíče ho není nutné explicitně uvádět. Obvykle příkaz vrací vložená data (včetně vygenerovaných hodnot). 127 | 128 | **Update** 129 | 130 | ```sql 131 | UPDATE Tabulka 132 | SET slopec_a = hodnota_a 133 | WHERE ... --často klíč 134 | ``` 135 | 136 | Update bez WHERE může provést update všeho. Kontrolují se integritní omezení 137 | 138 | **Delete** 139 | 140 | ```sql 141 | DELETE FROM Tabulka WHERE ... 142 | ``` 143 | 144 | Delete bez WHERE může provést smazání celého obsahu 145 | 146 | **Select** 147 | 148 | Trochu nabušený select: 149 | 150 | ```sql 151 | SELECT DISTINCT Tabulka.sloupec, B.sloupec FROM Tabulka 152 | JOIN TabulkaB AS B ON Tabulka.cizi_id = B.id 153 | WHERE price > 0 154 | ORDER BY sloupec ASC 155 | ``` 156 | *Join jde přepsat pomocí WHERE* 157 | 158 | Výsledek selectu lze dát do závorek a použít namísto nějaké tabulky, data mají pořád tabulární strukturu. 159 | 160 | Mezi daty se stejnou strukturou lze provést množinové operace `UNION`, `INTERSECT`, `MINUS`. 161 | 162 | U `WHERE` můžeme používat i příslušnost v množině hodnot `IN`, rozsahu `BETWEEN ... AND ...`, logické operátory `AND`, `OR`... U stringů `LIKE` kde `?` zastupuje znak a `%` několik znaků. 163 | 164 | **Pohled/View** 165 | 166 | - Uložený a pojmenovaný select, který se vykoná s provedením dotazu 167 | - view mají omezenou modifikaci dat (například nelze, pokud obsahuje agregaci, distinct, union...) 168 | => je lepší použít zdrojové tabulky 169 | 170 | **Materializovaný pohled/view** 171 | 172 | - View, jehož výsledek se předpočítává. Vrací se pak hodnoty přímo z nové tabulky, ale s každou změnou je třeba materializované view přepočítat (rychlejší čtení, pomalejší zápis). 173 | 174 | **Agregační funkce** 175 | 176 | Používané s `GROUP BY sloupec/sloupce` 177 | 178 | *Pokud nepoužijeme `GROUP BY`, počítají se agregační funkce ze SELECTu* 179 | 180 | - `COUNT(...)` - počet řádků, lze použít `COUNT(*)` 181 | - `AVG(...)` 182 | - `SUM(...)` 183 | - `MIN(...)` 184 | - `MAX(...)` 185 | 186 | Lze použít `HAVING ...`, což je `WHERE`, ale s použitím agregačních funkcí. 187 | 188 | ## Relační algebra 189 | > *[@thes01](https://github.com/thes01): více taky na [tomto odkazu (bc státnice)](https://docs.google.com/document/d/1SVbwwMDDfOCqAdsfTH1RDJex9_fZZ96wb0Vp2fSoUFs/edit)* 190 | 191 | **Relace** je podmnožinou kartézského součinu domén. Toto se promítne do databáze tak, že domény jsou datové typy sloupců a tabulka (složená ze sloupců) obsahuje pouze takové kombinace hodnot (řádky), jaké jsou v relaci. 192 | 193 | Pro relační operace používáme relační algebru skládající se z 194 | - **množinových operací** (ale pro sjednocení, rozdíl a průnik musí být relace kompatibilní, i.e., mít stejnou hlavičku) 195 | - **projekce** - i.e. výběr sloupců 196 | - **selekce** - i.e. WHERE 197 | - **přejmenování** - AS 198 | - **spojení/join/součin relací** - JOIN 199 | - **seskupení a agregace** - GROUP BY, AVG(...)... 200 | ...jednotlivé operace tedy odpovídají dotazovacímu jazyku SQL. 201 | 202 | Existují dotazy, které nejsme schopní vyjádřit relační algebrou, třeba tranzitivní uzávěr. 203 | 204 | *Tranzitivní uzávěr nad relací získáme tak, že se díváme na prvky množiny v relaci. Pokud je `a` v relaci s `b` a `b` v relaci s `c`, pak (aby bylo dosaženo tranzitivity) tranzitivní uzávěr obsahuje relaci `a` s `c`.* 205 | 206 | ## Integritní omezení 207 | 208 | Součástí DDL, jazyku definice dat. Určitým způsobem omezují, jakých hodnot mohou pole nabývat. E.g. `NOT NULL`, `UNIQUE`, `FOREIGN KEY .. RERERENCES ..(..)`, `CHECK(price>0)`... Uvádí se na příslušný řádek (ideálně), tabulky, jako dodatečný řádek tabulky, nebo jako samostatný výraz `ALTER TABLE .. ADD CONSTRAINT ... NOT NULL (id)`. 209 | 210 | ## Řízení transakcí. 211 | 212 | Transakce v RDBMS mají ACID vlastnosti 213 | - **Atomicity** - skupina příkazů transakce brána jako jednotka; provedou se všechny, nebo žádný 214 | - **Consistency** - po vykonání transakce ke db v konzistentním stavu, není porušeno žádné integritní omezení 215 | - **Isolation** - transakce je izolovaná od ostatních transakcí, je možné nastavit úrovně transakce, dle toho může transakce skončit chybou (pokud došlo k modifikaci stejného objektu, jaký modifikovala jiná transakce), nebo se využijí zamykací mechanismy 216 | - **Durability** - data jsou po vykonánání transakce persistentně uložena 217 | 218 | Transakce se potvrzují příkazem `COMMIT`, vrací příkazem `ROLLBACK` na stav před započením transakce, či po poslední `SAVEPOINT` 219 | 220 | ## Indexování 221 | 222 | Index slouží ke zrychlení/zefektivnění častých dotazů nad tabulkou. Dotazy obsahující zvolený sloupec (či jejich kombinaci) budou rychlejší. 223 | 224 | ```sql 225 | CREATE INDEX my_index ON Products (Price) 226 | ``` 227 | 228 | Pro indexy se mohou používat 229 | - **tradiční indexy** - jako v knihách, odkazy na řádky s danou hodnotou, je možné dělat více úrovní indexů, používat různá indexová uspořádání... 230 | - **haše** - pro získání jednoduché hodnoty velkých dat 231 | - **B+ stromy** - každý uzel obsahuje odkazy na uzly níže, nebo hodnoty (jedná se o listový uzel). Hodnoty jsou v listech vzestupně uspořádány, uzly v sobě mají i informace o intervalech daných odkazů/hodnot, listy jsou provázané. 232 | ![](img/20230526220652.png) 233 | - **R stromy** - podobné jako B+, ale jsou vícedimenzionální, ve 2D fungují jako obdélníky. Data jsou v listových uzlech stromu. Rodič uzlu zahrnuje všechny své potomky (ve 2D jde o větší obdélník, který obsahuje potomky). Ideální je, aby zabíraly rodičovské obdélníky co nejméně prostoru - rodič totiž jako index redukuje oblast nutnou k prohledání (říká *hledej ve mně!*). 234 | ![](img/20230526220927.png) 235 | ![](img/20230611232516.png) 236 | 237 | Další dělění indexů 238 | - **dense** - každý řádek je zaindexovaný, zabírá více místa, ale hledání je rychlejší 239 | - **sparse** - pouze některé řádky zaindexované, zabírá méně místa, ale hledání pomalejší (je potřeba dohledat konkrétní řádek) 240 | 241 | ## Hašování 242 | 243 | **Cílem hašování je převést vstupní data libovolné délky na výstup jednotné délky (fixed-length řetězec, nebo číslo), hash.** Z heshe by nemělo být možné odvodit vstup (**jednosměrnost**), pro každý vstup bychom měli být schopni deterministicky (vstupem jsou pouze data) určit jediný hash. Zároveň může být (dle použití) cílem minimalizovat riziko kolize, tedy že dva vstupy mají stejný hash (nelze se tomu ale vyhnout, protože musíme být schopni mapovat nekonečno možných vstupů na omezený počet výstupů daný délkou). Dle použití může být také důležité, aby podobné vstupy měli zásadně rozdílné heše, aby bylo možné snadno odhalit drobnou (záměrnou či nechtěnou) modifikaci vstupu. Pro prolamování hašů se použávají rainbow tables, obsahující pro daný algoritmus známé vstupy a jejich haše. 244 | 245 | Hašování se používá pro zajištění integrity dat (certifikáty, checksum), rychlé porovnávání dat (HashMap), porovnávání dat se znalostí pouze heše (uchovávání hash hesel v databázi, Argon2). 246 | 247 | **Bezkoliznost** 248 | - **slabá** - pro vstup A nejsme schopni v rozumném čase nalézt rozdílný vstup B, který by měl stejný hash 249 | - **silná** - nejsme schopni v rozumném čase najít libovolné dva rozdílné vstupy se stejným hashem 250 | 251 | Pro různé účely používáme různé algoritmy, jde o balanc rychlosti (u hesel může je kýžená pomalost) a bezpečnosti/pravděpodobnosti kolize. 252 | - **MD5** - relativně rychlý, není bezpečný (lze rychle najít kolize i na běžném počítači). 253 | - rodina Secure Hashing Algorithm, za bezpečnou se aktuálně považuje **SHA-2** (SHA256, SHA512, SHA-384...) 254 | - **Argon2** - v současnosti doporučovaný pro hašování hesel 255 | - hašem (hloupým, ale rychlým) může být třeba i délka vstupu, modulo, součet ascii hodnot znaků... (nazývá se [Cyclic redundancy check](./dev_3_bezpecny_kod.md#notes)) 256 | -------------------------------------------------------------------------------- /3_softwarove_inzenyrstvi.md: -------------------------------------------------------------------------------- 1 | # Softwarové inženýrství 2 | 3 | > Životní cyklus SW, proces vývoje a řízení softwarového vývoje. Metodika (Rational) Unified Process (UP, RUP), agilní metodiky a principy agilního vývoje SW. Nasazení a provoz softwarových systémů. Údržba softwarových systémů, znovupoužitelnost. Příklady z praxe pro vše výše uvedené. [PA017](https://is.muni.cz/auth/el/fi/podzim2020/PA017/um/cz/) 4 | 5 | ## Životní cyklus sw, proces vývoje a řízení softwarového vývoje 6 | 7 | Vždy nějakým způsobem obsahuje fáze analýza, návrh, implementace, testování a provoz (včetně nasazení). Rozdíly jsou v tom, zda a jakým způsobem dělíme projekt na uchopitelnější části. Důsledkem toho jsou i různé způsoby, jakým se vývoj řídí. 8 | 9 | Existuje několik základních modelů 10 | 11 | - **Vodopádový model** 12 | - Skládá se z: 13 | - **Analýza** 14 | - sběr požadavků klienta 15 | - Je důležité rozlišovat mezi tím, co říká že potřebuje, a co skutečně potřebuje. Pro lepší představu můžeme sledovat, jak koncový uživatel pracuje se současným řešením. 16 | - zajímá nás **co** a **proč**, často ale klient zmiňuje **jak**. V takových případech je důležité se ptát **proč**. Může jít o legitimní důvod, ale také třeba o nevědomost. 17 | => studie proveditelnosti, dokument požadavků... 18 | - **Návrh** 19 | - návrh architektury, jednotek, výběr technologií, plán testování 20 | => diagramy (uml), wireframy, prototypy 21 | - **Implementace** 22 | - tvorba systému dle návrhu 23 | - **Testování** 24 | - **Provoz** 25 | - i.e. nejprve sesbíráme všechny požadavky, pak sw jako celek postupně navrhneme, implementujeme, otestujeme a nasadíme 26 | - Výhody: 27 | - snadný na řízení 28 | - pokud vše jde hladce, je to nejlevnější způsob 29 | - Nevýhody: 30 | - většinou všechno nejde hladce 31 | - špatně se reaguje na změny (musíme se vracet do předchozích fází modelu) 32 | - zákazník předem nedokáže přesně a úplně definovat, co potřebuje 33 | - v praxi nejsou kroky v tomto pořadí dodržovány (testovat chceme ideálně při vývoji, něco chceme ukázat netrpělivému zákazníkovi...) 34 | 35 | - **Inkrementální model** 36 | - Projekt se rozdělí na inkrementy, části, které budou vyvíjeny a dodávány postupně, pro každý si uděláme jednoduchou rámcovou analýzu 37 | - Inkrementy se vyvíjí v pořadí podle priority 38 | - Po nasazení do systému máme o inkrementu od zákazníka zpětnou vazbu 39 | - Výhody: 40 | - Systém je dodáván po částech, celkové náklady jsou distribuovány 41 | - Není potřeba vytvářet velký tým, protože práce je dodávaná po částech 42 | - Uživatel vidí systém v raných fázích projektu. Lze rychle reagovat na zpětnou vazbu uživatele 43 | - O nutnosti změny se dozvíme dříve a její zavedení bude levnější (není třeba vše překopávat, přidáme změnový inkrement) 44 | - Nevýhody: 45 | - Náklady na vývoj jsou vysoké kvůli dodávce systému po částech 46 | - Model vyžaduje náročné plánování k distribuci práce 47 | - Pro připojení modulů vyvinutých s každou fází je nezbytné důkladně popsat rozhraní 48 | 49 | - **Spirála** 50 | ![](img/20230607122950.png) 51 | - kombinace iterací a vodopádu, důraz na analýzu rizik 52 | - vývoj probíhá v cyklech, každý má několik fází 53 | - fáze 54 | - **Analýza** 55 | - **Návrh** 56 | - **Implementace** 57 | - **Testování, zpětná vazba a plán dalšího cyklu** - zpětnou vazbu používáme pro práci v dalším cyklu 58 | - oproti inkrementálnímu modelu nemusíme mít po každé iteraci hotovou část nasazeného systému (inkrement je třeba ve formě jasných požadavků, návrhu systému, nebo tak). 59 | - cykly aplikujeme i na jednotlivé fáze vodopádu 60 | - lépe pracujeme s nejistotou, ale trvá to dýl 61 | 62 | - **Prototypování** 63 | - vytvoříme prototyp systému, abychom porozuměli, jakým způsobem chce zákazník systém používat a co od něj očekává 64 | - po analýze prototypu ho zahodíme a začneme práci na reálném systému, využijeme vhodný model 65 | 66 | - **Model výzkumník** 67 | - navrhni systém a implementuj ho. Vyhovuje? Super. Nevyhovuje? Zpět k návrhu/implementaci 68 | - nelze pořádně řídit, neexistuje dokumentace, řešitelé jsou obtížně nahraditelní, jde o experimentování 69 | 70 | - **V procesní model** 71 | - alá vodopád, ale zobrazuje i různé testy k fázím (jednotkové, integrační, systémové, uživatelské, akceptační...) 72 | 73 | Nezávisle na modelu je důležité nastavit správnou komunikaci, definovat a používat jednotný jazyk. Pokud chceme cokoliv řídit, je potřeba mít informace o aktuálním stavu, dodržování plánu, očekávaných změnách, problémech... 74 | 75 | Hlavní metodiky řízení sw projektů jsou **prediktivní metodiky (e.g. RUP)** a **agilní (e.g. SCRUM)**. 76 | 77 | ## Metodika (Rational) Unified Process (UP, RUP) 78 | - rigidní, důraz na procesy 79 | - vhodná, pokud máme jasné a pevné požadavky, variabilní aspekty mohou být čas a zdroje 80 | - vyžaduje podstatné plánování předem 81 | - iterativní a inkrementální, jednotlivé aktivity (plánování, požadavky, modelování, návrh, vývoj, testování, nasazení..) se částečně překrývají 82 | - řízena riziky, use-case požadavky 83 | - architektura je středobodem - existuje architektonický tým, se kterým ostatní týmy konzultují případné nejasnosti/problémy, slouží jako centrální komunikační uzel (lepší, než kdyby spousta dev týmů komunikovala navzájem) 84 | - umožňuje pevnou kontrolu nad procesy a týmem 85 | - vhodná, pokud potřebujeme pořádnou dokumentaci (UML diagramy) 86 | - hodí se pro velké a heterogenní produkty, velké týmy... 87 | - Výhody: 88 | - zákazník není při vývoji potřeba, definice produktu je zakotvena v kontraktu (přesně ví, co dostane) 89 | - Nevýhody 90 | - pracujeme s fixními deadliny, rozpočtem i funkcionalitou 91 | - v reálu se deadline a rozpočet může lehce měnit v závislosti na vývoji 92 | - změnové požadavky jsou problém 93 | - potřeba více času k plánování 94 | - složitý kontrakt, je třeba myslet na všechno (exhaustive kritéria přijetí, penále...) 95 | 96 | ![](img/20230523215135.png) 97 | - iterace jsou seskupovány do fází 98 | - **Inception** (1 iterace) 99 | - řešíme feasibilitu, zachycujeme klíčové požadavky, rizika 100 | - popis významných požadavků s dopadem na architekturu 101 | - identifikace actorů 102 | - identifikace dalších systémů, se kterými máme komunikovat 103 | - na konci známe cíle, hrubou architekturu 104 | - co se používá pro podobné systémy? s čím máme zkušenosti? 105 | - určení použitých technologií 106 | - určení orientační ceny, časového plánu a rizik 107 | => **Project brief** 108 | - **Elaboration** (2 iterace) 109 | - řešíme požadavky, architekturu, hrajeme si s UML diagramy 110 | - na konci máme architekturu, návrh systému reflektující požadavky 111 | - **Construction** (4 iterace) 112 | - tvoříme systém, testujeme, nasazujeme 113 | - na konci máme beta verzi, relativně stabilní a otestovanou, připravenou k použití 114 | - **Transition** (2 iterace) 115 | - hledáme a opravujeme chyby, děláme manuály, poskytujeme konzultace 116 | - testování s uživateli (beta, na základě feedbacku děláme změnové požadavky), akceptační testy 117 | 118 | - iterace by neměla překročit 3 měsíce, přínos iterace je **inkrement**, každá iterace obsahuje workflows, které jsou více či méně přítomné. Pro každé workflow se používají určité UML diagramy 119 | - **Business modelování** 120 | - activity diagram 121 | - **Požadavky** 122 | - use case diagram 123 | - **Analýza a návrh** 124 | - sequence, collaboration diagrams 125 | - **Implementace** 126 | - class, object, component diagrams 127 | - **Testování** 128 | - use case, class, activity diagrams 129 | - **Deployment** 130 | - deployment diagram 131 | 132 | RUP je konkrétní metodika stavějící na UP (přidává třeba jednotlivé role a odpovědnosti v týmu, konkrétní postupy...), UP je obecný rámec 133 | 134 | ## Agilní metodiky a principy agilního vývoje SW 135 | - flexibilní, důraz na lidi 136 | - radši budeme reagovat na změnu, než se pevně držet plánu 137 | - snažíme se fixovat čas a zdroje, proměnlivá může být funkcionalita (*Postavili jsme dům a plot, v rozpočtu zbývají zdroje na garáž, nebo bazén. Co z toho chcete?*) 138 | - vhodná, pokud se požadavky mění, není jasná kýžená výsledná podoba systému, nebo zákazník požaduje něco hmatatelného relativně brzo 139 | => není přesné datum dokončení 140 | - vyžaduje minimální plánování předem 141 | - klíčová je dobrá komunikace a spolupráce týmu 142 | - automatizované testování 143 | - variabilita funkcionality (vývoj postupuje tak, že když dojde čas/peníze, tak se ptáme zákazníka, zda něco přihodí, nebo zda vyškrtneme nějakou část systému) 144 | - face-to-face komunikace, rychlé meetingy - rychlejší, získáme lepší porozumění 145 | - jednoduchá dokumentace - dokumentace těžko udržuje tempo s realitou, proto ji držme co nejjednodušší, ideálně navázanou na kód 146 | - častá setkání se stakeholdery (sprint review), prezentace nové funkcionality (lepší, než jen popis) 147 | - e.g. 148 | - extreme programming - osvědčené postupy tahá do extrému (osvědčují se reviews? => dělej reviews co to jde) 149 | - párové programování, důraz na testy, refaktorizaci, kód je single source of truth (dokumentaci generujeme z kódu, používáme schéma pro generování ostatních věcí...) 150 | - rychlá zpětná vazba, důraz na jednoduchost, malé inkrementy 151 | 152 | ### SCRUM 153 | - nejčastěji využívaná agilní metodika 154 | - iterativní, inkrementální 155 | - jednoduchý, očekává se použití i dalších nástrojů/procesů 156 | - vhodný pro menší týmy (<=15 lidí) 157 | - hodí se, když máme tým schopný samostatnější práce, potřebujeme rychle vytvořit aspoň nějaký produkt 158 | 159 | - role 160 | - **product owner** - reprezentuje stakeholdery, má největší přehled o požadavcích na produkt, spravuje product backlog 161 | - **scrum master** - zodpovědný za dodržování scrumu, řeší procesy 162 | - **tým vývojářů** - 3-9 lidí, soběstačný (má lidi na všechno) a sebeorganizující se, spravují sprint backlog, zodpovědný za doručení produktu 163 | 164 | - artefakty 165 | - **product backlog** 166 | - obsahuje veškerou zbývající požadovanou funkcionalitu ve formě **user stories** 167 | - jednotka funkcionality, testovatelná, logický celek 168 | - každé story má: 169 | - **story points** reprezentující časovou náročnost odhadnutou pomocí [planning pokeru](./3_softwarove_inzenyrstvi.md#planning-poker) 170 | - akceptační kritéria (testovatelná, formulovaná jako Given ... When ... Then ...) 171 | - může mít seznam rizik 172 | - stories mají prioritu (MoSCoW) dle hodnoty, náročnosti, rizika, přínosu... 173 | - Must - nezbytné 174 | - Should - mělo by být 175 | - Could - bylo by fajn 176 | - Won't/Wish - zapomeň na to, možná jindy 177 | - pro testování je možné použít Gherkin/Cucumber (As a ... I can ... So that ...) 178 | 179 | - tvořen celým scrum týmem, spravuje ho product owner 180 | - v praxi jde o tabuli (reálnou/virtuální) se sticky notes 181 | 182 | - **sprint backlog** 183 | - část product backlogu (množina user stories), která se má provést v daném sprintu 184 | - stories jsou rozděleny na jednotlivé tasky, u každého je určen časový odhad v hodinách 185 | - task má fáze Todo, In progress a Done 186 | - tasky si k práci vybírají vývojáři dle vlastního uvážení, ale žádné (ani user stories) nemohou být v rámci sprintu přidány/odebrány 187 | - bylo by nutné zrušit celý sprint product ownerem 188 | - spravován týmem vývojářů 189 | 190 | - **product increment** 191 | - všechny předměty product backlogu, které se splní během sprintu (a.k.a. to, co se za sprint stihne/udělá) 192 | - tvořen týmem vývojářů, testován zákazníkem, může být released product ownerem 193 | - je nutné, aby byl použitelný a byl splněn (dle definice scrum týmu) 194 | 195 | - události 196 | - **project planning** 197 | - tvorba [project charteru](./4_projektove_rizeni.md#pmi-project-management-body-of-knowledge-pmbok) 198 | - tvorba product backlogu 199 | - výběr klíčových strategií (komunikace, rizika, řízení změn, kvalita...) 200 | - **sprint planning** 201 | - probíhá na začátku sprintu, cca 8 hodin 202 | - účastní se celý scrum tým 203 | - vytyčuje se cíl nadcházejícího se sprintu (a.k.a. co chceme udělat), vybíráme věci z product backlogu a přiřazujeme jim tasky 204 | - **sprint** 205 | - iterace soustředěná na vývoj funkcionality v spring backlogu, cílem je vytvořit použitelný a potenciálně vydatelný product increment 206 | - pracuje na něm celý scrum team 207 | - product owner řeší komunikaci, vývojáři vývojaří, scrum master sleduje dodržování procesů 208 | - analýza, návrh, implementace, testování 209 | - max 1 měsíc, všechny sprinty trvají stejnou dobu 210 | - po sprintu sledujeme [team velocity](./3_softwarove_inzenyrstvi.md#team-velocity), podle ní máme lepší odhad pro budoucí plány, lze podle ní upravit rozsah sprint backlogu 211 | - **daily scrum (standup)** 212 | - 15 minut každý den, účastní se vývojáři a možná i scrum master 213 | - co jsem dělal včera, co budu dělat dneska, narazil jsem na nějaké problémy? 214 | - **sprint review** 215 | - 4 hodiny, účastní se celý scrum team a klíčoví stakeholdeři (e.g. zákazník, uživatel) 216 | - proběhne předvedení inkrementu 217 | - proberou se případné problémy, změny, odpovídá se na případné otázky stakeholderů 218 | - proberou se případné změny product backlogu 219 | - případně se přepočítá předpokládané datum dokončení 220 | - probere se, co by se mělo dělat dál, upraví se priorita/pořadí v product backlogu 221 | - **sprint retrospective** 222 | - 3 hodiny, účastní se scrum team 223 | - řeší se procesy - rozložení práce, splnil se cíl, je třeba něco upravit? 224 | - řeší se vztahy - klapalo to? potřebuje někdo užší spolupráci? 225 | - řeší se nástroje - dobrá komunikace? dostatečná transparentnost? 226 | - řeší se lidi - měl někdo trable? někoho pochválíme? 227 | - co nefungovalo, co můžeme zlepšit 228 | - ideálně se vymyslí jedno zlepšení procesů, které se v příštím sprintu bude používat 229 | - případně se upraví klíčové strategie, rizika 230 | - **project retrospective** 231 | - uzavření projektu s týmem 232 | - řešíme lessons learned, co se povedlo, nepovedlo... 233 | - poděkujeme všem 234 | 235 | - SCRUM může skončit, když 236 | - product backlog je prázdný (vše hotovo), nebo nepovažujeme (společně se stakeholdery) jeho obsah za důležitý 237 | - dojde čas/peníze 238 | - udělali jsme poslední sprint a je sice co spravovat, ale defekty jsou přijatelné 239 | - product owner/stakeholder se rozhodne ukončit projekt 240 | 241 | - návrh a architektura se mohou dělat průběžně pro jednotlivé user stories, nebo se do procesu zavádí jako standard (e.g. používáme vrstvenou architekturu, používáme tyto technologie...) 242 | 243 | - kontrakt se obvykle určuje podle toho, kolik (a jakých) lidí bude za dané období na projektu pracovat 244 | - super na flexibilitu, ale těžko se určuje výsledná cena/deadline 245 | - zákazník je zatažen do postupu vývoje, může hned dávat zpětnou vazbu, ale tento overhead vyžaduje extra čas 246 | 247 | - balancuje se Čas, Cena a Rozsah funkcionalit 248 | 249 | #### Burndown chart 250 | - Ukazuje kolik práce zbývá a jak si vedeme oproti plánu 251 | ![](img/20230525221317.png) 252 | 253 | #### Team velocity 254 | - dokončené story pointy za sprint, je vidět v Burndown Chartu v dy/dx, nebo jako samostatná křivka 255 | ![](img/20230525221638.png) 256 | 257 | #### Planning poker 258 | 259 | Pro každé story každý z týmu provede odhad, odhady se zveřejní najednou. následuje diskuze, dokud se na bodech za dané story všichni neshodnou (doporučené použité body jsou podle fibbonacciho posloupnosti) 260 | 261 | #### SCRUM Board 262 | 263 | Viditelný celému týmu, na jednotlivých lístcích tasků je vidět i zpracovávající člověk 264 | 265 | ![](img/20230525224009.png) 266 | 267 | ## Nasazení a provoz softwarových systémů 268 | - před nasazením je důležité systém otestovat v prostředí, které bude co nejbližší tomu produkčnímu 269 | - klíčové je v provozu logování událostí (abychom v případě chyby věděli, co se v systému dělo), monitoring, systém zpětné vazby 270 | - nasazení zahrnuje přípravu prostředí (instalace os, databází...), lze automatizovat/zjednodušit použitím Platform as a Service, případně kubernetes 271 | - před nasazením do provozu je fajn projít a zkontrolovat dokumentaci, která může být kvůli vývoji neaktuální 272 | - součástí nasazení je i školení uživatelů, abychom předešli neúspěchu z důvodu neochoty/neznalosti používání 273 | - součástí nasazení může být i customizace systému pro specifické potřeby zákazníka (pokud to náš systém umožňuje) 274 | 275 | ## Údržba softwarových systémů, znovupoužitelnost 276 | - v závěru je fajn si udělat analýzu toho, co (ne)fungovalo, co zlepšit... 277 | - dosažená produktivita a kvalita 278 | - použitý proces, odchylky, důvody 279 | - plán vs realita a důvody (čas, peníze, chyby, FP/LOC...) 280 | - rizika (plán vs realita, jak jsme řešili rizika a problémy) 281 | - pracnost (i dle etap) 282 | - souhrn defektů 283 | - kauzální analýza - analýza odchylek výkonu u použitého procesu (jak a proč) 284 | - použité technologie a jejich hodnocení 285 | - popsat v dokumentu tým a jednotlivce, na které je možné se případně obrátit (třeba když se řeší problém v dalším projektu) 286 | - aktiva procesu - co vzniklo a může být použito i v jiných projektech (třeba knihovny, checklisty...) 287 | - údržba se může dělat jako samostatný projekt, mohou na to být specializované týmy 288 | - řeší se oprava (i bezpečnostních) chyb, aktualizace a vylepšení (ideálně nějakým způsobem automatizované, ale může být fajn potvrzení uživatele), správu změn (co se jak a proč změnilo) 289 | - znovupoužitelnost se obvykle řeší v rámci jednotlivých služeb/programů/komponent, ale ne znovupoužitím struktur mezi různými projekty (pokud nejde o specializovanou knihovnu) - mohli bychom mít problém v případě změny 290 | -------------------------------------------------------------------------------- /4_projektove_rizeni.md: -------------------------------------------------------------------------------- 1 | # Projektové řízení. 2 | > Plánování, řízení rizik, role modelů v projektovém řízení. Ganttovy diagramy, síťová analýza, metoda kritické cesty (CPM), Program Evaluation and Review Technique (PERT). Mezinárodní standardy a metodiky projektového řízení (PMI Project Management Body of Knowledge, PRINCE 2). Příklady z praxe pro vše výše uvedené. [PA179](https://is.muni.cz/auth/el/fi/jaro2022/PA179/um/) 3 | 4 | ## Plánování 5 | 6 | Je třeba rozlišovat mezi 7 | - **Projekty** 8 | - dočasné - mají start i konec, typické fáze (příprava, provedení, uzavření, případně fáze sw životního cyklu) 9 | - přinášející změnu, dodávají hodnotu stakeholderům (všem zúčastněným; uživatelům, zákazníkům i dodavatelům produktu...) 10 | - unikátní - každý má svá specifika (požadavky, zákazníky, tým...), nejedná se o každodenní rutinnou práci firmy 11 | - plánované 12 | - opakovatelné prvky projektu (či celé projekty) jsou **procesy** - řízené událostmi, bývají dobře definované (jak postupovat), vizualizované flow chartem 13 | > proces je opakovatelná série aktivit s definovanými vstupy, výstupy, nástroji, technikami... 14 | - bývají spojené s rizikem - spojené s unikátností (nikdy jsme to nedělali), deadliny, děláme nějakou změnu 15 | - **řízení** 16 | - balanc mezi časem, cenou a rozsahem/kvalitou 17 | - začneme užíváním standardů (PRINCE2, PMBOK, IPMA), abychom efektivněji komunikovali, koordinovali, zvýšili důvěru stakeholderů, transparentnost, abychom znovu neobjevovali vymyšlené 18 | - **Programy** - skupina dočasných, vzájemně provázaných projektů řízená jako skupina abychom dosáhli cílů, které projekty sdílí 19 | - **řízení** 20 | - správa rizik 21 | - odstraňování omezení a konfliktů z projektů 22 | - v projektech se přemýšlí a plánuje i s ohledem na jiné projekty programu 23 | - **Portfolio** - skupina projektů a programů, řízená k dosažení dlouhodobých strategických cílů 24 | - a.k.a. co dlouhodobě nabízíme 25 | - **řízení** 26 | - monitoringem výkonu firmy 27 | - výběrem a prioritizací programů a projektů 28 | 29 | Pro konkrétní projekt je potřeba si zvolit vhodný přístup **prediktivní** nebo **agilní** [viz otázka 3](./3_softwarove_inzenyrstvi.md). 30 | 31 | ### Agilní plánování 32 | Dále je potřeba u plánování projektů sepsat [Project Charter](./4_projektove_rizeni.md#pmi-project-management-body-of-knowledge-pmbok) popisující základní informace o projektu (proč, co, kdo, kdy, jak, za kolik...), sepsat podrobnosti klíčových strategií (komunikace, rizika, kvalita, změny) a nějakým způsobem začít plánovat práci (product backlog, řešení architektury...). 33 | 34 | ### Prediktivní plánování 35 | 36 | Sepisuje se **Project Initiation Documentation** obsahující detailní Business Case, veškeré informace o projektu (proč, co, kdo, kdy, jak, za kolik), definují se klíčové strategie (komunikace, rizika, kvalita, změny), vše se dokumentuje, vytváří se příslušné registry, vše se schvaluje product boardem (zástupci exekutivy, inženýrů a zákazníků). Do PID se pak zapisují i změny a průběh, aby bylo možné porovnat plán a realitu, je dostupný všem v rámci projektu. 37 | 38 | Dělá se detailní analýza požadavků, spousta Use case diagramů, detailní rozsah sloužící jako základ pro ocenění, design mockupy. Tvoří se **specifikační dokument** produktu - obsahuje požadavky, rozbití systému na komponenty (včetně detailního popisu až po pole vstupních formulářů), očekávanou kvalitu, akceptační kritéria. 39 | 40 | Dělá se **projektový plán** (proč, co, kdo, kdy, jak, za kolik...) - **Work Breakdown Structure** tvořená ze specifikačního dokumentu, počítá se čas a cena jednotlivých **Work Package**s (součást WBS, nejnižší jednotka) třeba pomocí [PERT](./4_projektove_rizeni.md#program-evaluation-and-review-technique-pert), jejich závislosti, tvoříme rozvrh (gantt/network diagram), přiřazujeme odpovědnosti (mělo by jít snadno najít aktivity člověka i všechny spojené s aktivitou). 41 | *WBS* 42 | ![](img/20230526000518.png) 43 | 44 | ## Řízení rizik 45 | Postup: 46 | 1. Identifikace rizik 47 | - čerpáme z předchozích zkušeností, lessons learned... co a proč se stalo? 48 | 2. Ohodnocení rizik 49 | - každé riziko způsobí náklady, můžeme pro něj odhadnout cenu 50 | - každému přiřadíme pravděpodobnost a kritičnost dopadu, určíme následky 51 | ![](img/20230525214112.png) 52 | 3. Určení odezev na rizika, možnosti: 53 | - akceptuj - no tak se to stane, no, nevadí, náklady na prevenci by byly vyšší než samotné riziko 54 | - vyhni se - nastavení plánu, aby problém nemohl nastat (e.g. použití jiné technologie, která tento problém nemá) 55 | - přesuň (třeba na někoho jiného) - e.g. tento komponent outsourcujeme se solidním SLA, nebo se pojistíme 56 | - zmenši - sniž pravděpodobnost/míru dopadu rizika, třeba důkladnějším systémem reviews 57 | 4. Stanovení monitoringu rizik 58 | - stanovení odpovědnosti za monitoring rizik 59 | - určení, kde budou rizika definována, kdy budou revidována a upravována 60 | 5. Vytvoření registru rizik 61 | 62 | Možné zdroje rizik (nejčastější tučně): 63 | - uživatel - **nemožnost/neochota zapojit se**, odpor ke změnám 64 | - požadavky - **špatně pochopené**, blbě definované, nejasné či neadekvátní, **přijdou změny** (mnohdy až v momentě, kdy mohou zásadně narušit vyvíjený systém) 65 | - složitost projektu - komplexní doména, použití nové/nezavedené technologie 66 | - management - **neefektivní řízení**, špatně zvolená/použitá metodika/standard, **špatný odhad nákladů/zdrojů/času**, špatně určená komunikace, **nezkušený manažer** 67 | - tým - nezkušenost, **málo lidí**, osobní konflikty 68 | - firemní prostředí - nestabilní, změna vedení... 69 | - **subdodavatelé** - opoždění, nedostatečná kvalita, komunikace... 70 | 71 | ### Specifika prevence u agilního řízení rizik 72 | Prevence: 73 | - **Transparence a zpětná vazba**, abychom předešli nedorozumění v týmu 74 | - **Používání user stories** - jsou snadno pochopitelné pro zákazníka, dají se dobře ověřovat 75 | - **Jasná definice, co znamená "hotovo"** 76 | - **Krátké iterace** - brzo zjistíme, co je případně blbě 77 | 78 | ## Role modelů v projektovém řízení 79 | 80 | Těžko říct, co se tím myslí; v přednáškách PA179 žádná významná zmínka o modelech nebyla :thinking: 81 | Datové modely? Modelování komunikace, financí, rizik? 82 | 83 | V řízení lze modely použít při plánování projektů pomocí [síťové analýzy](./4_projektove_rizeni.md#síťová-analýza), [metody kritické cesty](./4_projektove_rizeni.md#metoda-kritické-cesty-cpm). 84 | 85 | Dále je možné modelovat procesy (komunikace), finance, rizika... a na těchto modelech hledat kritická místa, zkoumat co by kdyby... 86 | 87 | ## Ganttovy diagramy 88 | - nástroj pro plánování (nejen) projektů 89 | V základu toto: 90 | ![](img/20230525192847.png) 91 | 92 | ale lze rozšířit... 93 | 94 | - y osa obsahuje úlohy (případně zdroje) 95 | - x osa zobrazuje čas 96 | - úloha jako uzel/obdélník (šířka udává časovou náročnost), případná hrana značí vztah 97 | - je možné přidat 98 | - milestones 99 | - progress 100 | - zdroje (kdo co dělá, dávají se místo událostí na osu y), pak řešíme problém plánování job-shopu 101 | - omezení, precedenční podmínky (úloha musí být započata až po dokončení jiné úlohy, něco je možné paralelizovat...) 102 | - obvykle minimalizujeme makespan (čas dokončení poslední úlohy a tedy i celého projektu) 103 | ![](img/20230525195955.png) 104 | 105 | ## Síťová analýza 106 | 107 | Metody pro modelování souboru činností vedoucích k dosažení nějakého cíle (i.e. projektů). 108 | 109 | Cílem je projekt naplánovat, minimalizovat prostoje a náklady, určit termíny, celkovou dobu trvání projektů, identifikovat kritické úlohy v projektu. 110 | 111 | Používá se pro to síťový graf hranově/uzlově orientovaný - úlohy jsou na hranách/uzlech. Uzlově orientovaný umožňuje snadno modelovat precedenční podmínky, lze snadno použít pro metodu kritické cesty. 112 | 113 | ## Metoda kritické cesty (CPM) 114 | 115 | Metoda pro identifikaci vzájemně závislých aktivit, které mají vliv (jsou kritické) na dobu dokončení projektu a nemohou být opožděny bez prodloužení dokončení projektu. 116 | 117 | [Postup](https://www.youtube.com/watch?v=4oDLMs11Exs) 118 | 119 | - uděláme si graf závislostí, určíme si dobu trvání aktivit 120 | - v prvním průchodu jdeme start => konec, řešíme earliest start/completion time. Když vedou 2 do 1, bereme maximum těch 2. 121 | - v druhém průchodu jdeme konec => start, řešíme latest completion/start time. Když vedou 2 z 1, bereme minimum těch 2. 122 | - kritická cesta obsahuje aktivity, které mají earliest & latest finish time identický 123 | - slack/float udává, o kolik můžeme danou aktivitu opozdit, aniž by došlo ke zpoždění projektu (`latest completion time - earliest completion time`) 124 | 125 | ![](img/20230526101347.png) 126 | 127 | ## Program Evaluation and Review Technique (PERT) 128 | 129 | Technika k odhadu času k dokončení tasku. Bereme **optimistický** odhad, **pesimistický** odhad a **nejpravděpodobnější** odhad 130 | 131 | `očekávaný = (optimistický + 4 * nejpravděpodobnější + pesimistický) / 6` 132 | 133 | Pokud máme informace o úrovni platů implementátorů tasků, můžeme dopočítat odhadovanou cenu. 134 | 135 | ## Mezinárodní standardy a metodiky projektového řízení 136 | - standardy projektového řízení PRINCE2, PMBOK, IPMA ICB popisují obecnější způsob řízení 137 | - metodiky sw vývoje (RUP, SCRUM) řeší řízení v rámci vývojového týmu, jsou specifické pro vývoj SW 138 | 139 | ![](img/20230525184623.png) 140 | 141 | ### PMI Project Management Body of Knowledge (PMBOK) 142 | - **procesně orientovaný** standard, podrobně popsaná sada good practices 143 | - snadno se používá jako handbook pro vhodné znalostní oblasti a nástroje/techniky při životním cyklu projektu 144 | - vhodný, když 145 | - manažer potřebuje tipy na nástroje a techniky, jaké by měl použít, ale aspoň trochu tuší co a jak 146 | 147 | - 49 procesů (série aktivit s definovanými vstupy, výstupy, nástroji a technikami) dělených do 148 | - 5 procesních skupin, logické dělení procesů podle fází (inicializace, plánování, provedení, monitoring a řízení, uzavírání) 149 | - 10 vědomostních oblastí/disciplín projektového managementu, každá má vlastní procesy 150 | - Integrace 151 | - tvorba **Project Charter**u 152 | - **Business case (proč)** - cíle projektu, hrubá cena, rozpočet, rizika 153 | - **Project outcome (co)** - popis, hlavní cíle a požadavky 154 | - **Stakeholders (kdo)** - externí i interní, řešíme jejich role, potřeby, zapojení a odpovědnosti 155 | - **Management approach (jak)** - popis použitých standardů, nástrojů, metodik, životního cyklu projektu... 156 | - **Schedule (kdy)** - hrubý plán projektu, fáze, milestones, Ganttův diagram.. 157 | - Rozsah (scope) - sesbírání požadavků, definice, validace a řízení rozsahu funkcionalit systému, tvorba Work Breakdown Structure 158 | - Plán - definice a určení pořadí aktivit, odhady časů aktivit, tvorba a řízení plánu 159 | - Cena - odhad cen a rozpočtu aktivit nebo jednotek práce pomocí Work Breakdown Structure, řízení ceny a rozpočtu 160 | - Kvalita - plánování, řízení a kontrola kvality 161 | - Zdroje - odhad nepeněžních a lidských zdrojů, jejich získávání a řízení, tvorba a správa týmů 162 | - Komunikace - plán, správa a kontrola komunikace a informací o projektu 163 | - Riziko - identifikace, kvalitativní (míra dopadu) a kvantitativní (pravděpodobnost) analýza rizik, jejich monitoring, plán a procesy reagující na rizika 164 | - Dodavatelé - produkty a služby pocházející mimo náš tým, kontrakty, objednávky, SLAčka, výběr dodavatelů, monitoring výkonu dodavatelů 165 | - Stakeholdeři - zúčastněné osoby; jejich identifikace, plánování a správa zapojení stakeholderů do projektu 166 | 167 | ### PRINCE 2 (PRojects IN Controlled Environment) 168 | - standard pro řízení obecného projektu 169 | - předepsaný postup, krok za krokem (spousta formulářů na vyplňování, checklisty) 170 | - součástí není správa požadavků, rozpočtování 171 | - vhodný pro 172 | - nutnost velkého reportování 173 | - nutnost kompletní projektové dokumentace 174 | - tým vyžaduje řád a kontrolu 175 | - manažery s málo zkušenostmi, hodí se mu podrobný popis postupu 176 | 177 | - fáze (hrubě odpovídá UP inception, elaboration, construction a transition) 178 | - **Starting up** 179 | - tvorba **Project brief** 180 | - řešíme feasibilitu, zachycujeme klíčové požadavky, rizika 181 | - popis významných požadavků s dopadem na architekturu 182 | - identifikace actorů 183 | - identifikace dalších systémů, se kterými máme komunikovat 184 | - na konci známe cíle, hrubou architekturu 185 | - co se používá pro podobné systémy? s čím máme zkušenosti? 186 | - určení použitých technologií 187 | - určení orientační ceny, časového plánu a rizik 188 | - plán další fáze 189 | - **Work Breakdown Structure** 190 | - identifikace aktivit, dependencí 191 | - odhad trvání aktivit, stanovení milestones 192 | - definice rolí a odpovědností 193 | - tvorba rozvrhu (Gantt/síťový diagram) 194 | - **Initiation** 195 | - tvorba **Project Initiation Documentation** (dokument/vícero dokumentů) 196 | - obsahuje současný stav projektu, plány, Kdo, Co, Kdy, Jak, Proč, Za Kolik... 197 | - slouží k definici projektu, určení rámce... 198 | - schvaluje product board 199 | - detailní Business Case (důvody projektu, očekávání, cost-benefit analýzu, časovou škálu, ceny, rizika) 200 | - popis struktury managementu, rolí týmu 201 | - popis přístupu ke kvalitě, změnám, riziku, komunikaci 202 | - plán projektu 203 | - plán další fáze 204 | - **Delivery** 205 | - obvykle má více částí (iterací), každá max 3 měsíce, každá má definované měřitelné a ověřitelné milestones 206 | - produktový manažer se stará o udržení ceny, termínů, rozsahu a kvality specifikované v PID 207 | - produktový manažer autorizuje, provádí reviews work packages, reportuje (pravidelně) status, změny, problémy a kvalitu výš, spravuje rizika a problémy 208 | - týmový manažer provádí týmové plánování (jednotlivých work packages), demonstruje kvalitu produktu, zajišťuje dodání work packages 209 | - mezi fázemi se hodnotí končící fáze a plánuje (zase WBS, gantt) další, aktualizuje se PID 210 | - **Close** 211 | - předání produktu (samozřejmě opět spousta protokolů), nasazení, uzavření všech dokumentů, PID, dokumentace, tvorba end report a lessons learned 212 | - případné předání projektu ops a maintenance týmu 213 | - tvorba SLA 214 | 215 | - 7 principů (vše máme nějak zdokumentované) 216 | - **Kontinuální odůvodnění projektu** - proč to děláme? 217 | - **Učení se ze zkušeností** - co (ne)fungovalo 218 | - **Role a odpovědnosti** - přesně specifikovaná struktura týmu, vymezené práva a odpovědnosti 219 | - **Řízení po fázích** - po každé fázi děláme review Project brief, provádíme reporting vyššímu managementu 220 | - **Manage by exception** - řízení soustřeďujeme na části, které se nějak (negativně) vymykají. Nezasahujeme do toho, co funguje. Vytyčíme cíle a tolerovatelné odchylky v kvalitě, času, ceně a rozsahu, určíme zodpovědnosti za nepřekračování 221 | - **Důraz na produkt** - primární cíl je produkt, ne práce 222 | - **Přizpůsobení metodiky projektu** - není nutné PRINCE používat úplně doslovně, řádek po řádku. Ne všechny formuláře jsou vždy zcela relevantní 223 | 224 | - 7 témat 225 | - **Business case** - obsahuje očekávané přínosy, rizika, časový a cenový rozsah, důvody projektu... Měl by být neustále aktualizován a držen validní po celou dobu projektu 226 | - **Organizace** - definice rolí a odpovědností, typy stakeholderů (dodavatel, business/zákazník, uživatel), 3 úrovně managementu (project board pro směrování projektu (obsahuje exekutivu, senior suppliera, senior usera), project manager pro řízení projektu, team manager pro dodávání produktu), manage by exception 227 | - **Kvalita** - monitoring, akceptační kritéria, určíme si strategii řízení kvality (nástroje, procesy), řešíme kvalitu produktu i manažerských výtvorů (plány, reporty) 228 | - **Plány** - plánujeme projekt i jednotlivé fáze, Gantt diagram, Work Breakdown Structure je základem plánování 229 | - **Rizika** - identifikace možných rizik, určujeme způsob reakce na dané riziko na základě ceny prevence, pravděpodobnosti a dopadu, uchováváme registr rizik 230 | - **Změny** - u požadavků na změnu řešíme prioritu, dopad, kritičnost, zkoumáme možnosti řešení, dle změny upravujeme záznamy a plán 231 | - **Postup projektu** - porovnáváme realitu s plány (čas, cena, kvalita, rozsah, rizika...), sledujeme zda stále projekt splňuje business case 232 | 233 | - 7 procesů 234 | ![](img/20230525115631.png) 235 | - **Úplný začátek projektu** - nastínění business case, přiřazení klíčových vedoucích osob, studování "lessons learned" předchozích podobných projektů, získání autorizace product boardu 236 | - **Inicializace projektu** - příprava strategií řízení (rizik, kvality, komunikace, konfigurace), projektového plánu, konkretizace business case, založení dokumentace 237 | - **Řízení fáze** - řeší produktový manažer, monitoring, reportování významných událostí, řídíme exceptions, revidujeme a schvalujeme práci/nové části produktu 238 | - **Řízení dodání produktu** - to samé co řízení fáze, ale řeší to týmový manažer 239 | - **Směrování projektu** - vysokoúrovňová rozhodnutí, funguje po celou dobu projektu, plán nadcházející fáze, na konci projektu autorizujeme uzavření 240 | - **Řízení mezi fázemi (managing a stage boundary)** - plán nadcházející fáze, řeší produktový manažer, aktualizace business case a projektového plánu, report předchozí fáze 241 | - **Uzavření projektu** - řeší projektový manažer, evaluace, předání produktu, návrh board na ukončení 242 | 243 | ### IPMA ICB 244 | *V otázce není, ale není na škodu znát* 245 | - obecný standard pro vedení projektu 246 | - narozdíl od většiny ostatních obsahuje podrobnou sekci o soft skills 247 | - vhodný, když 248 | - projekt vyžaduje dobré soft-skills (komunikace, leadership, řešení konfliktů) 249 | - manažer je zkušený, zná procesy 250 | - není nutná spousta reportingu 251 | - vhodné pro použití jako handbook pro různé manažerské kompetence 252 | - kompetenční přístup, pro každou ICB popisuje požadované dovednosti a schopnosti, popis a metriky indikátorů kompetence 253 | > kompetence je aplikace znalostí (knowledge, informace & zkušenosti), dovedností (skill, schopnost aplikovat znalosti) a schopností (ability, použití dovedností efektivně, ve správný čas a na správném místě) k dosažení kýženého výsledku 254 | - kompetence perspektivy - metody a techniky pro interakci jedinců s prostředím 255 | - lidské kompetence - techniky pro jednání s jedinci/skupinami 256 | - praktické kompetence - metody a techniky pro úspěch projektu 257 | 258 | ### Metodiky 259 | - popsány v [otázce 3](./3_softwarove_inzenyrstvi.md) 260 | 261 | ## Notes 262 | 263 | Specifika IT projektů v porovnání s většinou průmyslových odvětví 264 | - nepřesné/neznámé, časté a měnící se požadavky 265 | - větší nutnost přizpůsobení produktu 266 | - velká složitost 267 | - náročné testování 268 | - neustálý a rapidní vývoj technologií 269 | - možnost globální spolupráce 270 | - projekty mohou v rámci portfolia ovlivnit ostatní projekty (zvlášť při selhání) 271 | - nutnost řízení rizik 272 | - dokončené projekty je často třeba servisovat/poskytovat podporu 273 | 274 | IT Infrastructure Library (ITIL) 275 | - best practices pro **řízení IT služeb** 276 | - fáze 277 | - **Service strategy** - požadavky, strategie pro zajištění kýženého, finance, co vlastně budeme dělat 278 | - **Service design** - Service Level Agreement, řešení rizik, security & business compliance 279 | - **Service transition** - jak měníme stávající služby, řešení deploymentu, uložení získaných znalostí pro budoucí projekty 280 | - **Service operation** - dokumentace pro uživatele/helpdesk, řešení incidentů/změnových požadavků/problémů, řešení identit a přístupu k systému 281 | - **Continual service improvement** - monitoring, logování, aktualizace běžící služby 282 | -------------------------------------------------------------------------------- /dev_2_zpracovani_dat.md: -------------------------------------------------------------------------------- 1 | # Zpracování dat. 2 | 3 | > Základní pojmy a principy datových skladů, datové analytiky a business intelligence. Životní cyklus datového skladu. Analytika velkých dat, jazyky pro realizaci analytických úloh, analytika na úrovni databází. Pokročilé techniky zpracování dat, výkonnostní aspekty zpracování velkých dat. Příklady z praxe pro vše výše uvedené. ([PA220](https://is.muni.cz/auth/el/fi/podzim2021/PA220/um/), PA036) 4 | 5 | ## Základní pojmy a principy datových skladů, datové analytiky a business intelligence. 6 | 7 | **Business intelligence** 8 | - procesy a nástroje pro sběr, analýzu a prezentaci/vizualizaci dat za účelem asistence při tvorbě informovaných rozhodnutí v podnikovém řízení 9 | - umožňuje transformaci dat do informací 10 | - jádrem je datový sklad 11 | 12 | **OLTP vs OLAP** 13 | - OLTP (online transaction processing) 14 | - způsob ukládání dat v db pro transakční zpracování 15 | - data v databázi se mění, cílem je zajistit konzistenci a umožnit CRUD 16 | - nutné zamykání tabulek/řádků pro zajištění konzistence 17 | - vhodné pro uložení dat v operativním provozu podniku (zajímá nás, co máme na skladě, jaká je aktuální cena produktů...) 18 | - normalizovaná forma (není datová redundance, používají se public keys pro případné spojování dat) 19 | - používané queries známe dopředu 20 | 21 | - OLAP (online analytical processing) 22 | - způsob ukládání dat pro analytické zpracování 23 | - data v databázi se nemění 24 | - zamykání není třeba, data se nemodifikují 25 | - pracujeme s mnohem větším objemem dat 26 | - vhodné pro dlouhodobé uložení dat, reflektuje historii dat z produkční databáze a jejich vývoj v čase 27 | - denormalizovaná forma, hodně indexů, snažíme se minimalizovat nutné joiny, nevadí datová redundance 28 | - **hvězdicové schéma/dimenzionální modelování** - středobodem je vždy nějaký subjekt (obsahující fakta e.g. prodej) s **tabulku faktů** (obsahující konkrétní záznamy měření), ke které se pomocí referencí (foreign key) vážou **tabulky dimenzí** (často odpovědi na otázky KDO, KDY, KDE, JAK..., obvykle detailní (denormalizované) pro snadnou analytiku, redundance nevadí, e.g. datum dělíme na den, měsíc, rok, den v týdnu, kvartál... můžeme mít separé date i time dimenze, obvykle 4-15). Čím více dimenzí máme, tím více/konkrétněji se můžeme DW dotazovat (dimenze tvoří kontext). Tabulky dimenzí obvykle předvyplníme (pro datum můžeme použít numerický přepis data, e.g. 20230621), rozlišujeme dimenze data a času. Jako stěžejní data (to, co nás zajímá) bereme fakta, dimenze jsou popisná data k faktům, podle kterých je možné seskupovat. Reference jsou jen v tabulce faktů. ID pro tabulky (surrogate keys, int) dimenzí si generujeme sami, abychom nebyli limitování použitými klíči z OLTP. 29 | ![](img/20230611150321.png) 30 | - typy faktů 31 | - transakční, událost spojená s hodnotou (e.g. nákup) 32 | - snapshot - zachycující nějakou aktuální hodnotu (e.g. naplněnost skladu) 33 | - bez hodnoty - fakt nemá žádnou numerickou hodnotu, obvykle jde o nějakou událost (e.g. click na určitý prvek) 34 | Za fakty se považují i odvozená data (e.g. kumulativní hodnoty za nějaké období), nebo data kombinovaná z vícero procesů (e.g. prodeje a jejich předpovědi pro dané období). Ty obvykle neukládáme do tabulky faktů (ale může to mít své opodstatnění, třeba pro zrychlení dotazů) 35 | - nevadí nám drobná neaktuálnost dat 36 | - query neznáme dopředu, záleží na tom, co chceme zjistit 37 | ![](img/20230610171630.png) 38 | 39 | **Snowflake schema** - star schema, kde dimenze mají hloubku (obsahují reference na další tabulky, e.g. obsahující month ID a month name). Způsobují performance problémy, jde o antipattern. 40 | 41 | ![](img/20230611150909.png) 42 | 43 | **Granularita** popisuje, z jaké úrovně se na fakta díváme (e.g. zajímá nás, kolik se prodalo daného produktu? Za jeden den? V konkrétním obchodě?). Nejnižší granularita je jeden fakt (ukládáme opravdu fakty, nebo třeba jen agregovaná data?). 44 | 45 | **Měření/Measure** - aspekt faktu, který nás zajímá, lze agregovat (e.g. cena prodeje). Některé hodnoty měření lze sčítat (e.g. tržby), některé jen v některých dimenzích (e.g. zůstatek na pokladnách, nelze sčítat v čase), některé vůbec (e.g. cena za jednotku produktu nebo průměrná cena za období...) 46 | 47 | **Conformed (přizpůsobivá?) dimension** - dimenze, která má stejné hodnoty a význam pro data pocházející z vícero zdrojů. E.g. čas je obvykle conformed dimenze, pobočka nemusí být (pod jakou pobočku by spadal prodej přes internet?). 48 | 49 | **Datový sklad** 50 | - OLAP 51 | - oddělení od OLTP, abychom nezatěžovali produkční db 52 | - obvykle 1 db fungující jako centrální zdroj pravdy pro analýzu a reporting 53 | - data ve skladu se nemění, pouze přidávají, je vidět vývoj dat v čase 54 | - může obsahovat data z vícero zdrojů 55 | - vyžaduje, aby byla zdrojová data očištěna a konzistentně uložena 56 | - lze využít standardní databázi (e.g. postgres), nebo specialozovaná řešení (e.g. Google BigQuery, Teradata) 57 | - jednoduchá reprezentace dat, aby s nimi mohli pracovat analytici a bylo umožňěno používat jednoduché analytické dotazy (s minimem joinů) 58 | - cílem je umožnit a zjednodušit analýzu dat 59 | 60 | **Data mart** 61 | - malý data warehouse, soustředí se na jednu zájmovou jednotku (e.g. objednávky) 62 | - cílem je dekompozice za účelem zvýšení efektivity/omezení přístupu do jednotlivých částí datového skladu 63 | - mohou být dvě podoby 64 | - Nezávislé data marty - nemáme žádný centrální zdroj pravdy (DW), data do data martů jdou přímo ze zdrojů 65 | - Logické data marty - data marty fungují jako logické pohledy na část datového skladu, jednodušší na údržbu 66 | 67 | **Data Cube** 68 | - obsah DW, umožňuje pohled na data z různých dimenzí (rozměrů kostky, obvykle 4-15) 69 | - skládá se z buněk (cells) - každá je kombinací hodnot dimenzí. No data = prázdná buňka. 70 | - **Dense/sparse cube** - hodně/málo neprázdných buněk v data cube 71 | 72 | Na datový sklad/data marty jsou obvykle napojeny další **vizualizační aplikace** (e.g. Grafana, Kibana, PowerBI, nebo třeba R project) 73 | 74 | ## Životní cyklus datového skladu. 75 | 76 | Životní cyklus 77 | - **určení cíle a plánování** - co od systému očekáváme, jaký rozsah dat nás zajímá, odhad ceny, rizik, prioritizace subjektů (=> datamartů) 78 | - **návrh infrastruktury** - volba vhodných nástrojů a technologií, architektonických řešení 79 | - **návrh a vývoj data martů** - iterativně tvoříme data marty, každý zapojujeme do DW systému 80 | - **volba procesu** - včetně modelování procesu (třeba UML diagramem, nebo BPMN), e.g. prodeje 81 | - **určení granularity** - e.g. prodej jednoho produktu (jedné položky z objednávky) jednomu zákazníkovi, na jedné pobočce v jeden moment 82 | - **identifikace dimenzí** - vychází z granularity, můžeme dimenze rozšířit o další jevy (e.g. den v týdnu, slevové akce...) 83 | - **identifikace faktů** - všech sloupců, které budou v tabulce faktů (e.g. cena jednotky produktu, prodané množství) 84 | - čištění dat a jejich přidání do DW systému 85 | - **ETL (Extract, Transform, Load)** - v průběhu života do skladu přibývají data, které je vždy třeba 86 | - **extrahovat** z datových zdrojů (e.g. produkční db) 87 | - **transformovat** 88 | - odstranit duplicity 89 | - upravit, aby odpovídala jednotnému stylu v DW, učesat do formátu používaném v DW 90 | - vyčistit od nekompletních dat/chyb (spelling errors) 91 | - občas může být třeba rozbít data na vícero sloupců (name => first name, last name) 92 | - lze částečně automatizovat, ale mnohdy jsou třeba manuální zásahy 93 | - obvykle nevkládáme přímo do dw, ale do staging table (může být csv ve formátu dw tabulek) 94 | - je fajn dělat po částech, ať se do toho nezamotáme 95 | - **naplnit** (load) do DW 96 | - nejprve aktualizujeme dimenze (abychom měli k dispozici foreign keys), pak fakta 97 | - upsert (update, insert if not exists) je často drahý -> je fajn detekovat neexistující, pak vložit nové, a pak updatovat 98 | - je fajn naplňovat po velkých částech (e.g. indexy/materializovaná views přepočítat až po vložení, ne po každém řádku, stejně tak integrity checks) 99 | - může pomoct, když vkládáme předřazená (presorted) data 100 | - paralelizace (jednotlivé dimenze, tabulky faktů i partitions tabulek faktů lze provádět souběžně) 101 | 102 | ![](img/20230610173720.png) 103 | 104 | 105 | **Změny dimenzí** 106 | - dimenze se mohou v průběhu života DW měnit (změní se třeba region, pod který spadá pobočka) 107 | - možnosti implementace změny 108 | - **Přepis** - nahradíme stará data novými, je to jednoduché, ale ztrácíme informaci o historii 109 | - **Přidání sloupce s předchozí verzí (a valid from)** - vyřeší problém, ale při další změně čelíme stejnému problému 110 | - **Verzování** - tabulce dimenzí přidáme sloupce `valid from` a `valid to`, při změně pouze upravíme `valid to` a přidáme řádek pro novou hodnotu dimenze 111 | - **Přidání dimenze** - výběr aktuální verze musíme řešit jen v případě, že nás daná hodnota zajímá (e.g. mění se přiřazení obchodu do regionu, ale ne v každém dotazu nás zajímá region) 112 | Pokud často pracujeme s aktuální hodnotou, můžeme použít verzování, ale držet i aktuální hodnotu v separé sloupci. 113 | 114 | Přístupy tvorby datových skladů 115 | - top-down - analogie vodopádu, nejdříve analyzujeme datové zdroje, pak navrhneme a implementujeme sklad, nakonec naplníme daty a vytvoříme data marty 116 | - bottom-up - iterativně-inkrementální přístup, postupně pro každý zájmový objekt analyzujeme zdroje, postavíme data mart a případně rozšíříme (pokud nějaký centrální používáme) datový sklad 117 | 118 | ## Analytika velkých dat, jazyky pro realizaci analytických úloh, analytika na úrovni databází. 119 | 120 | **Big data** - jedná se o data, které kvůli své rychlé a kontinuální tvorbě, velkému objemu, či složitosti, vylučují zpracování tradičními analytickými způsoby. 121 | - Rychlý příchod dat vyžaduje kontinuální zpracování. Nepoužíváme batch processing, je potřeba stream processing (pro distribuované zpracování velkého množství zpráv/předání dat mezi systémy třeba Apache Kafka). 122 | - Velikost dat lze zvládat pomocí distribuovaných databází/souborových systémů (obvykle NoSQL databáze, nebo Hadoop Distributed File System) 123 | - pro zvládání složitosti dat (komplexní vztahy, či data typu video) je nutné použít specializované nástroje (pro vztahy třeba grafovou databázi). 124 | 125 | **Přístupy ke zpracování (nejen) velkých dat** 126 | - **batch** - jednou za čas aktualizujeme náš DW, doplníme nově vzniklá data 127 | - **stream** - průběžně vkládáme data tak, jak vznikají (důležité je udržovat konzistentní formát dat), snadněji se škáluje 128 | 129 | **Jazyky pro realizaci analytických úloh** 130 | - Tradičně jde o SQL, nebo jeho deriváty, které datoví analytici dobře znají. 131 | - Pro pokročilejší zpracování lze využít model MapReduce (a Hadoop), ve kterém je možné specifikovat transformační uzly v jakémkoliv programovacím jazyce 132 | - NoSQL databáze mohou mít vlastní rozšíření sql, nebo úplně jiný přístup k analytickým dotazům (e.g. mongo má knihovny pro různé jazyky) 133 | 134 | **Druhy sql dotazů specifické pro analytiku** 135 | - **Slice** - v rámci jedné dimenze vybíráme konkrétní hodnotu a zobrazujeme pouze data s touto hodnotou dimenze. V sql pomocí WHERE. E.g. kolik se prodalo laptopů? 136 | - **Dice** - jako slice, akorát pracujeme s intervaly/vícero hodnotami jedné dimenze (e.g. prodeje od-do, prodeje laptopů a telefonů), nebo hodnot vícero dimenzí (prodeje laptopů v říjnu) 137 | - **Roll-up** - provádíme agregaci dat. Dimenzionální - můžeme vynechat nějakou dimenzi (kolik jsme prodali za celý čas? kolik ve všech pobočkách?) nebo hierarchický - můžeme se dívat z pohledu vyšší úrovně nějaké dimenze (kolik jsme prodali v jednotlivých regionech, které se skládají z vícero poboček?). Oba přístupy lze kombinovat. V sql pomocí agregačních funkcí (GROUP BY a třeba SUM) 138 | - **Drill-down** - opak roll-upu, jdeme z abstrakce do většího detailu. Je nutné, aby nějaká detailnější data existovala. Obvykle děláme drill-down z nějakého materializovaného pohledu a jdeme na konkrétní data. 139 | 140 | **Pivoting** 141 | - přeskládání a agregace dat za účelem vizualizace 142 | - nejjednodušší variantou je **kontingenční tabulka** (cross table), ve které se zaměřujeme na dvě dimenze: 143 | ![](img/20230611214059.png) 144 | - v SQL se dříve muselo provádět pomocí sjednocení (union) několika příkazů 145 | ![](img/20230611214616.png) 146 | - nyní je v SQL možné použít (uvádím i příklady, je možné uvést více sloupců pro vícedimenzionální kontingenční tabulky) 147 | - `GROUP BY ROLLUP(year, band)` - vrací *polovinu* kontingenční tabulky (vrátí data, agregaci pro každý rok a celkovou agregaci) 148 | ![](img/20230611215146.png) 149 | - `GROUP BY CUBE(year, band)` - vrací celou kontingenční tabulku (vrátí data, agregaci pro každý rok, agregaci pro každou skupinu a celkovou agregaci) 150 | ![](img/20230611215253.png) 151 | - `GROUP BY GROUPING SETS(...)` - umožňuje větší kontrolu nad agregací dat (lze mimo jiné realizovat příkazy ROLLUP, CUBE) 152 | ![](img/20230611215834.png) 153 | 154 | **Přístupy k implementaci OLAP** 155 | - **Relational OLAP (ROLAP)** 156 | - data ukládáme v relační databázi (e.g. postgres), dimenze simulujeme pomocí star schema, pro dotazování používáme standardní SQL 157 | - (+) není potřeba specializovaný systém 158 | - (+) dobrá flexibilita 159 | - (-) response time 160 | - (-) zabírá 3-4x více místa, než MOLAP (v případě dense cubes) 161 | - **Multidimensional OLAP (MOLAP)** 162 | - data ukládáme ve speciálních multidimenzionálních strukturách (e.g. in-memory db, nebo multidimenzionální pole/matice kde používáme přímou adresaci na disku) 163 | - rychlejší queries než ROLAP, zabírá míň místa (není potřeba ukládat foreign keys) 164 | - horší flexibilita (při přidání hodnoty do domény dimenze je nutné přidat velké množství buněk, u ROLAP jde o jeden řádek v tabulce dimenze) 165 | - je potřeba specializovaný systém 166 | - mnohdy bývá součástí/add-on databázového řešení (MS SQL Server, Oracle...) 167 | - **Hybrid OLAP (HOLAP)** 168 | - kombinace MOLAP a ROLAP 169 | - čistá data uložena v ROLAP 170 | - agregace uloženy v MOLAP 171 | - => flexibilita, rychlost, ale vyšší složitost systému 172 | 173 | ## Pokročilé techniky zpracování dat, výkonnostní aspekty zpracování velkých dat. 174 | 175 | Pro zajištění rychlosti dotazů v OLAP se používá redundance v podobě 176 | - materializovaných pohledů (vkládáme jednou za čas, takže to není problém) 177 | - indexů 178 | - denormalizovaného schéma 179 | 180 | **Indexy** - umožňují rychlejší získání dat, která nas zajímají, pomocí předpočítaných výsledků. Omezují prostor nutný k prohledání při čtení dat. 181 | - obvykle se používají [B+ stromy](./5_databaze.md#indexování), ty jsou však limitovány jen pro 1D data, nejsou vhodné pro více dimenzí 182 | - **UB stromy** - multidimenzionální data jsou linearizovány pomocí Z-křivky a následně indexovány pomocí B* stromu (jako B+, akorát tam jsou jiná pravidla pro rebalanc). Linearizace Z-křivkou poskytuje dobrý výkon pro intervalové dotazy a zajišťuje, že data, která si byla blízká původně si budou blízká i po linearizaci. Indexovat do linearizovaných dat lze pomocí konverze souřadnic na binární číslo a naslédném prokládání bitů souřadnic. 183 | |![](img/20230611224121.png)|![](img/20230611224138.png)| 184 | |---|---| 185 | |![](img/20230611224805.png)|![](img/20230611224906.png)| 186 | - **R stromy** - obdélníky, popsány v [otázce 5](./5_databaze.md#indexování), špatně se škálují do mnoha dimenzí 187 | - **Bitmap indexy** - vhodné pro dimenze s málo variantami (e.g. pobočky). Pro každou variantu uděláme bitové pole o délce tabulky faktů. Index v poli odpovídá řádku v tabulce faktů. U pole nastavíme 1 pro indexy, ve kterých varianta platí, jinak 0. Výhodou je, že se snadno používají bitové operace (AND, OR) a je možné takto pracovat i s rozdílnými dimenzemi. Při mazání v tabulce faktů je třeba buď upravit všechny bitmap indexy, nebo v tabulce faktů použít *tombstone* hodnotu (považujeme za prázdnou). 188 | - **Range-encoded bitmap indexy** - vyžadují, aby měla dimenze seřazené hodnoty variant (jinak stejně nemá cenu hledat pomocí intervalů). Opět má každá varianta bitové pole délky tabulky faktů. Pokud je varianta pro daný fakt pravdivá, nastavíme ji, a všechny následující varianty v pořadí, na hodnotu 1 (jinak 0). (Hodnota neznamená e.g. *narodil se v měsíci*, ale *byl už na živu v měsíci*) Při intervalovém dotazu pak stačí provést ` AND (NOT )`. 189 | ![](img/20230612104455.png) 190 | 191 | **Partitioning** - dělení dat (tabulky) na více (nepřekrývajících se) částí 192 | - přístupy 193 | - logické - dělíme dle data/organizační jednotky/kategorie... nebo kobinace těchto faktorů 194 | - fyzické - distribuce dat na různé výpočetní uzly, umožnění paralelního zpracování na více strojích 195 | - může být implementováno přímo v databázovém systému, nebo si ho zajistíme na aplikační úrovni (náročnější) 196 | - typy dělení 197 | - horizontální - tabulku dělíme na vícero tabulek se stejnými sloupci, obvykle podle intervalu (často časová dimenze, případně nějaká, co se často nemění), ale je možné i třeba podle hashe 198 | - vertikální - část sloupců přesuneme do jiné tabulky (a.k.a. row splitting, vztah 1:1), dává smysl když určité sloupce nepoužíváme často. 199 | - data používaná společně by měla být uložena společně 200 | - fajn pro škálování, části lze nezávisle prohledávat na více strojích 201 | - nevýhodou je vyšší složitost systému, při vertikálním dělení jsou drahé joiny 202 | - doporučuje se dělat partitioning, když má tabulka >100 milionů řádků/je větší než 2GB 203 | 204 | **Optimalizace JOINů** 205 | - JOINy jsou 206 | - komutativní (nezáleží na pořadí operandů, `A JOIN B = B JOIN A`) 207 | - asociativní (nezáleží na závorkách, když chceme použít víc operandů, `(A JOIN B) JOIN C = A JOIN (B JOIN C)`) 208 | => pořadí JOINů lze přeskládat, abychom získali rychlejší provedení SQL dotazu 209 | - obvykle optimalizace provádí databázový systém 210 | - počet kombinací pořadí joinů je `n!` -> pro jednoduché queries je možné zkoumat všechny možnosti, u složitějších je nutné použít metaheuristiky (e.g. genetické algoritmy) 211 | - uživatel může poskytnout hinty/vnutit vlastní plán (pokud víme, co děláme, můžeme být snadno lepší) 212 | - pokud jsou dimenze dost restriktivní (filtrují hodně faktů), může být vhodné udělat cross join dimenzí 213 | 214 | **Pohledy** 215 | - klasický pohled (**view**) připomíná funkce v programovacích jazycích - pojmenovaný dotaz. Při dotazu nad view se automaticky provede selekce dat 216 | - **materializovaný pohled** funguje jako klasický pohled, ale má předpočítaný výsledek, uložený v tabulce (funguje jako cache), takže dotazy na materializovaný pohled jsou rychlejší. Při změně underlying dat se musí data materializovaného pohledu přepočítat/rozšířit (lze odložit, ale pak máme nekonzistenci), což u OLAP není zas takový problém, jako u OLTP. 217 | - vhodné pro často používané a drahé dotazy/části dotazů 218 | 219 | **Sloupcové databáze** - na rozdíl od řádkových databází (e.g. Postgres), kde jsou uloženy vedle sebe data náležící jednomu řádku ukládají sloupcové databáze (e.g. BigQuery, S4HANA) vedle sebe data z jednoho sloupce. Díky mohou být sloupcové databáze rychlejší pro čtení dat. 220 | 221 | **In-memory databáze** - namísto uložení dat na pevném disku držíme data v RAM -> rychlejší přístup, ale mnohem vyšší cena. E.g. S4HANA 222 | 223 | **Distribuované databáze** - umožňují horizontální škálování, svou distribuovaností umožňují fault-tolerance (díky replikaci dat), e.g. Hadoop Distributed File System, Apache Cassandra. 224 | 225 | **NoSQL (not only sql)** 226 | - key-value stores - data ukládáme/hledáme pomocí klíče, snadno se používají jako cache e.g. Redis 227 | - dokumentové databáze - data ukládají ve formě dokumentů (každý má klíč, podkle kterého se referencuje, jinak je to klasická struktura/třída) a kolekcí dokumentů, e.g. Mongo, Firebase 228 | - sloupcové databáze (column family, wide-column) - data jsou organizována do tzv. "rodin sloupců" (column families), které mají společné vlastnosti nebo jsou často používány společně, e.g. Cassandra 229 | - grafové databáze - snadno modelují entity a vztahy, e.g. Neo4j 230 | - obvykle nebývají ACID (a nepoužívají joiny), díky čemuž mohou být rychlejší. Větším problémem je udržení konzistence dat. Některé poskytují distribuci dat na více výpočetních uzlů out of the box (co vím tak mongo, cassandra) 231 | 232 | ### Apache Hadoop 233 | 234 | - **platforma pro paralelní/distribuované zpracování velkých datasetů** 235 | - batch processing 236 | - vysoká dostupnost zajištěna replikací dat 237 | - využívá **Hadoop Distributed File System (HDFS)** 238 | - distribuovaný souborový systém vhodný pro immutable data 239 | - abstrahuje distribuovanost, uživatel pracuje s daty jednotným způsobem 240 | - high availability díky replikaci, data rozdělena do bloků (defaultně 128MB), každý je v HDFS replikován (defaultně 3x, každá replikace na jiném stroji) 241 | - jeden stroj je **name node** (master), ostatní **data nodes**. Master má přehled o mapování souborů na bloky a jejich lokaci na data nodes (tato data jsou taky replikována). Pro získání dotazu klient kontaktuje mastera (zjistí, kde má hledat data) a následně kontaktuje příslušné data nodes. 242 | - datové bloky jsou write-once (díky čemuž nemusíme řešit zamykání a dosahujeme vyšších rychlostí čtení) 243 | - spolu s HDFS využívá modelu **MapReduce** 244 | - umožňuje paralelní zpracování dat 245 | - uživatel definuje jen použité map a reduce funkce (může jich být vícero) 246 | - postupně probíhá Map, Grouping a Reduce fáze 247 | - **Map** - transformace dat (filtrování, sorting). Bere vždy jednu položku dat (e.g. řádek) a vrací 0-1 key-value pár. Tímto způsobem zpracuje všechna data 248 | - **Grouping** fáze - děje se automaticky po map fázi, seskupuje data se stejným klíčem (vznikne key-list) a předá data se stejným klíčem jednomu reduceru 249 | - **Reduce** - agregace dat podle klíče, sumarizace výsledků Map operací. Bere key-list (obsahující všechny hodnoty pro daný klíč) a vrací key-list (obsahující 0-n výstupních záznamů). 250 | E.g. word count - map bere řádek a vrací několik (dle výskytu na řádku) dvojic `(slovo, 1)`. Reduce sečte `1` pro daná slova a vrací `(slovo, součet)`. 251 | ![](img/20230612201616.png) 252 | 253 | ### Apache Hive 254 | - distribuovaný data warehouse postavený nad Hadoop (a HDFS) 255 | - poskytuje SQL-like (HiveQL) rozhraní pro dotazy, které je převedeno do MapReduce dotazů (je možné dělat i vlastní map reduce skripty) 256 | - umožňuje používání strukturovaných dat (struktury, seznamy, mapy) 257 | - umožňuje serializaci/deserializaci dat do/z různých formátů (xml, csv, json...) 258 | - vhodný pro dlouho běžící ETL jobs 259 | - pokud chceme low latency/interactive queries, je vhodnější použít Apache Impala (SQL query engine nad Hadoopem) 260 | 261 | ### Stream processing 262 | 263 | - nezpracováváme balík dat, ale kontinuální stream 264 | - Apache Spark (analytický engine pro large-scale data processing, umí batch i stream processing) 265 | - Apache Storm (real-time výpočty, skládá se ze zdrojů dat a acyklicky propojených zpracovávajících uzlů) 266 | 267 | ## Notes 268 | 269 | ### Příklad architektury Data Warehouse pro Big Data 270 | 271 | ![](img/20230612205443.png) 272 | -------------------------------------------------------------------------------- /2_kvalita_kodu.md: -------------------------------------------------------------------------------- 1 | # Kvalita kódu 2 | 3 | > Kvalita ve vývoji softwarových systémů, atributy kvality a softwarové metriky. Taktiky pro zajištění kvality na úrovni jednotlivých atributů kvality. Principy Clean Code a SOLID, refaktoring kódu. Testování kódu, jednotkové testy, integrační testy, uživatelské a akceptační testy. Ladění a testování výkonu. Proces řízení kvality ve vývoji softwarových systémů. Příklady z praxe pro vše výše uvedené. [PV260](https://is.muni.cz/auth/el/fi/jaro2023/PV260/um/lectures/), PA017, PA103 4 | 5 | ## Kvalita ve vývoji softwarových systémů 6 | 7 | - důležitý aspekt při vývoji sw systémů, 8 | - kvalita je často definována jako **schopnost produktu dostát požadavkům** => je důležité si určit, co jsou požadavky 9 | - **zákaznické požadavky** a.k.a. externí kvalita (použitelnost, přesnost/správnost, spolehlivost, bezpečnost, výkon..) 10 | - abychom dostáli těmto ^, je třeba, aby šel vývoj snadno, aby se produkt dal jednoduše dlouhodobě udržovat (byl snadný modifikovat/rozšířit), a aby nebyl zbytečně drahý (skrz náklady na provoz i cenu úprav). Toho docílíme dodržováním **interní kvality produktu** (modularita, jednoduchost jednotek, testovatelnost, přizpůsobitelnost změnám, čitelnost kódu, znovupoužitelnost, škálovatelnost, přenositelnost, udržitelnost, dodržování standardů...) 11 | - špatná externí kvalita je často symptomem špatné interní kvality produktu (opravy chyb trvají dlouho, systém je pomalý... ale nemusí to být vždy pravda, třeba jen máme slabší UI) 12 | 13 | ## Atributy kvality 14 | 15 | - za nejdůležitější atributy kvality kódu se považují 16 | - **Udržitelnost (maintainability)** = snadnost úprav bez technického dluhu 17 | - **výkonnost** = reakční doba systému (a efektivita využití zdrojů) 18 | - **Spolehlivost** = pravděpodobnost bezchybného fungování po určitou dobu 19 | - **Testovatelnost** = jak snadno (a co všechno) lze systém testovat 20 | - **Škálovatelnost** = schopnost systému zpracovat větší množství dat/uživatelů.. 21 | - **Bezpečnost** = jak je systém odolný vůči útokům 22 | - **Použitelnost** = snadnost používání systému a jednoduchost učení se práce s ním, správná funkcionalita (obvykle samostatný bod) 23 | 24 | ## Softwarové metriky 25 | - měřitelné aspekty sw systému (počet řádků kódu, pokrytí testy, cyklomatická složitost...), které nám dávají informace o celkovém obrazu, ale může být netriviální je vhodně interpretovat 26 | - e.g. 100% pokrytí testy nemusí znamenat, že v systému nejsou chyby. Velký počet malých tříd zní dobře, ale třídy mohou být naprosto nelogicky strukturované a vzájemně silně závislé... 27 | - mohou být přímé (to co přímo změříme, e.g. počet defektů) nebo odvozené (vypočítané z přímých, e.g. hustota defektů; počet defektů na velikost produktu) 28 | 29 | - **Lines of code** 30 | - **(Non)Commented lines of code** - řádky (ne)obsahující komentář 31 | - **Počet tříd** 32 | - **Počet funkcí/metod** 33 | - **Počet packages** 34 | - **Počet souborů** 35 | - **Provázanost tříd** - kolik jiných tříd voláme 36 | - **Hloubka dědičnosti** 37 | - **Počet metod na třídu vážený složitostí** 38 | ... 39 | - **Cyklomatická složitost** - počet nezávislých cest ve zkoumané jednotce (obvykle funkce), kterými se může běh vydat 40 | `= - + 2` 41 | - nejnižší je 1 (bez větvení) 42 | 43 | často nás spíš zajímají poměry/odvozené metriky, e.g. procento komentů z celkového počtu řádků, průměrná velikost metody, odchylky v rámci projektu/mezi releases... 44 | 45 | - metriky je nebezpečné používat k ohodnocení výkonu vývojáře 46 | 47 | ## Taktiky pro zajištění kvality (pro jednotlivé atributy) 48 | 49 | - **Udržitelnost (maintainability)** - refaktoring na koherentní jednotky, aby bylo místo nutné změny minimální a snadno lokalizovatelné, separace dat od logiky (aby bylo možné jednotku nahradit jinou), decoupling (závislosti na rozhraních, namísto na implementacích) 50 | - **Výkonnost** 51 | - kešování 52 | - paralelismus 53 | - asynchronní komunikace/zpracování 54 | - detekce a mitigace bottlenecků 55 | - odstranění adaptérů, zjednodušení komunikace 56 | - separace dat od logiky 57 | - **Spolehlivost** 58 | - detekce a náprava zdrojů nespolehlivosti 59 | - kontrolní mechanismy pro zajištění spolehlivosti 60 | - vhodné ošetření chyb, 61 | - automatický reporting neočekávaných chyb, 62 | - timeout po requestu 63 | - pravidelný ping (iniciuje volající služby) 64 | - heartbeat (služba pravidelně reportuje stav) 65 | - pravidelné snapshoty a rollback v případě pádu 66 | - transakce 67 | - kontrola vstupů na každé úrovni 68 | - odstranění single point of failure 69 | - **Testovatelnost** 70 | - refaktoring na závislosti na abstrakcích, decoupling 71 | - separace dat a logiky 72 | - odstranění globálního stavu 73 | - **Škálovatelnost** 74 | - refaktoring na jednodušší, samostatně nasaditelné jednotky 75 | - extrakce dat pro umožnění paralelizace jednotek 76 | - extrakce a samostatné nasazení subsystému 77 | - distribuce a/nebo replikace dat (db bývá bottleneck, ostatní věci lze snadněji paralelizovat) 78 | - **Bezpečnost** 79 | - detekce a oprava chyb 80 | - použití šifrované komunikace 81 | - **Použitelnost** 82 | - zlepšení UX 83 | - použití taktik pro zlepšení výkonnosti/škálovatelnosti (když je to pomalý) 84 | 85 | ## Clean Code 86 | 87 | - čitelný, snadno pochopitelný. Kód bývá mnohem více čten než psán, proto je důležité, aby byl srozumitelný, čas vývojářů je drahý. Klíčové je 88 | - **jasné pojmenovávání** reflektující doménu problému, dostatečně výstižné (a ne příliš dlouhé či generické, viď, Javo). V ideálním případě by mělo být sebevysvětlující a komentáře by neměly být potřeba, ALE i tak jsou komentáře fajn pro vysvětlení myšlenky, nebo shrnutí, co má daná funkce dělat 89 | - důležitá je konzistence napříč codebase (ideálně stavěná na standardech daného jazyka) 90 | - pokud vrací bool, pojmenuj to `has*()` nebo `is*()` 91 | - struktury jsou podstatná jména, metody začínají slovesem (nebo se jedná o getter v rustu) 92 | - veřejné API (public) jednotky by mělo být jasné a jednoduché, interně (private) se mohou používat delší názvy metod, když je díky tomu jasnější, k čemu slouží 93 | - **rozumná velikost jednotek** - ideálně krátké funkce, jednoduché třídy... single responsibility principle. Obsah jednotky by měl reflektovat její název 94 | - **užívání standardů** jazyka/technologie 95 | 96 | Dále se řídí principy: 97 | 98 | ### Don't repeat yourself (DRY) princip 99 | - každá informace by měla být v systému jednoznačně definována na jediném místě 100 | - e.g. dokumentaci generujeme ze zdrojáku, abychom neměli více sources of truth 101 | - e.g. definujeme schéma (prisma), ze kterého vygenerujeme jak SQL tabulky, tak struktury pro náš jazyk 102 | - e.g. vytáhneme sdílenou funkcionalitu do vlastní funkce 103 | - ... platí na vše, co může být v systému duplikováno (ale i v procesech, třeba opakované manuální spouštění testů => automatizovat) 104 | 105 | ### Keep it simple stupid (KISS) princip 106 | - jednoduchost před výkonem 107 | - nejlépe fungují systémy, které jsou co nejjednodušší 108 | - není důvod používat složité techniky na jednoduché problémy 109 | 110 | ### You Ain't Gonna Need It (YAGNI) 111 | - nezabýváme se tvorbou něčeho, co nebudeme potřebovat (e.g. neděláme přílišné abstrakce pro podporu možné budoucí funkcionality, pokud to není nutné) 112 | - je lepší věc udělat jednoduše a pak ji snadno upravit, než ji udělat univerzálně, abychom pak zjistili, že nás nenapadl nějaký edge case a musíme to stejně celé přepsat. Vývoj postupuje po malých krůčcích. 113 | 114 | ## SOLID 115 | 116 | - **Single responsibility** 117 | - každá třída by měla mít pouze jednu zodpovědnost, a.k.a. pro každou třídu by měl být pouze jeden důvod, proč by se měla změnit (e.g. FileReader by se měl starat pouze o čtení ze souboru, ne o zpracovávání čtených dat. Pouze změna způsobu čtení ze souboru může zapříčinit, že musíme měnit FileReader) 118 | => nižší provázanost (závislosti) tříd, vyšší koheze (zaměřenost na jednu věc), flexibilnější kód... 119 | 120 | - **Open/closed principle** 121 | - Otevřeno pro rozšíření, uzavřeno pro modifikaci, preferujeme přidávání nové funkcionality před změnou zdrojového kódu/binárky toho, co už máme 122 | => menší šance, že něco rozbijeme, na nových třídách nic nezávisí 123 | - používá se implementace rozhraní/abstraktní třídy 124 | - dodržování OCP způsobuje vyšší komplexitu (a třeba v rustu trochu ubírá výkon díky nutnosti dynamic dispatch), takže je potřeba ho používat obezřetně a jen tam, kde se často mění/přidává funkcionalita 125 | 126 | - **Liskov substitution principle** 127 | - instance tříd by měly být nahraditelné jejich podtřídami, aniž by došlo k narušení chování systému - všechny podtřídy by měly dodržovat kontrakty nadtříd a neměly by odstraňovat chování nadtříd 128 | - problém je, když musíme explicitně ověřovat, o jaký podtyp se jedná - toto by měl řešit polymorfismus 129 | - pokud dvě třídy sdílí mnoho funkcionality, ale nejsou nahraditelné, je vhodné je upravit na podtřídy nové třídy obsahující sdílené chování 130 | 131 | - **Interface segregation principle** 132 | - klienti kódu by neměli být závislí na metodách, které nepoužívají, a.k.a. dělej malá a jednoduchá rozhraní namísto velkých 133 | - e.g. chci v rustu převést strukturu na string. Jediné co proto musím udělat je zajistit implementaci Display traitu (a ničeho jiného). 134 | 135 | - **Dependency inversion** 136 | - moduly by měly záviset na abstrakcích (rozhraní), ne na konkrétních implementacích 137 | - snižuje se tím provázanost modulů, je možné poskytnout vlastní implementaci či mockovat 138 | - konstruktur by měl přijímat vše, na čem struktura závisí, ne si vytvářet zdroje sám (e.g. repo si nemá tvořit připojení do databáze, ale má být předáno v konstruktoru) = dependency injection konstruktorem 139 | 140 | ## Refaktoring 141 | 142 | - úprava modulu takovým způsobem, aby se nezměnilo jeho externí chování, ale pouze došlo ke zlepšení jeho interního struktury/modifikovatelnosti... 143 | - před refaktoringem je důležité mít chování solidně pokryto testy, abychom nezpůsobili nechtěnou změnu 144 | - během refaktoringu neděláme nic jiného (žádná nová funkcionalita) 145 | - techniky (některé editory je podporují, což usnadňuje práci a je pravděpodobně spolehlivější) 146 | - **Extrakce funkce** - kus kódu funguje jako jednotka/potřeboval by komentář => vytáhni ho do funkce, dej tomu přiléhající jméno, bude možné to použít na více místech 147 | - **Inline funkce** opak -//-, vhodné pro triviální situace jako `isMoreThanFiveEven(x)` 148 | - **Nahrazení funkce metodou struktury** - fajn, když funkce používá ranec proměnných => stanou se fieldy struktury 149 | - **Move method/field** - z jedné do jiné struktury, pokud to dává smysl (třeba doménově) 150 | - **Extrakce/inline třídy** - z třídy obsahující množinu polí, která jsou related, vytáhneme nový objekt, který bude původní třída obsahovat/nebo naopak pro inline 151 | - **Early return** - obecně chceme, aby funkce popisovala správný/bezchybný tok programu. Pokud při zpracování funkce objevíme chybu ve vstupních datech, hodíme tam return. V takových případech nepoužíváme `if-else`, ale `if return` 152 | - **Rename** cokoliv 153 | - **Seskupení mnoha parametrů do struktury** 154 | 155 | Kód, který se dobře čte a udržuje nemusí být ten nejrychlejší/nejefektivnější (abstrakce mohou něco stát). Obvykle nám mírné snížení výkonu za vyšší čitelnost nevadí, ale nemusí to být vždy pravda. 156 | 157 | ## Testování 158 | = proces evaluace, zda systém splňuje specifikované požadavky... což se snadněji řekne, než dělá 159 | - v praxi je testování z pravidla nekompletní. Testováním odhalujeme chyby, ale nedokazujeme bezchybnost. 160 | - každý test by měl testovat pouze jednu věc/vlastnost/feature, ideální je spousta malých testů, díky čemuž můžeme snadno identifikovat zdroj problému. 161 | - ideálně by měl testování provádět někdo jiný, než autor testovaného kódu 162 | 163 | - **whitebox (strukturální)** - vidíme zdrojový kód a můžeme vstupy testů cílit na spouštění kritických míst (off-by-one error, zero division...) 164 | - e.g. unit, integration, performance tests 165 | - **blackbox (funkcionální)** - nevidíme co se děje uvnitř systému, pouze sledujeme vstupy a výstupy 166 | - e.g. acceptance tests, system tests 167 | 168 | - pokud narazíme na chybu, pro kterou nebyl test, je důležitá nejen oprava, ale i přidání (ideálně automatizovaného) testu, aby se chyba už nemohla opakovat 169 | - regresní testování - sledujeme, zda změny v systému nepřinesly pády (automatizovaných) testů 170 | - smoke testy - sledujeme, zda vybrané kritické funkce fungují v novém prostředí. Pokud ne, nemá vůbec cenu nasazovat a testovat další věci 171 | - sanity testy - jako smoke, ale spouští se pro ověření nápravy chyb/přidání funkcionality 172 | - A/B testování - používáme dvě varianty a sledujeme, která je úspěšnější (obvykle při testování UI) 173 | - :hahaa: v praxi někteří experti praktikují melounové testování pro zvýšení test coverage, zvenku zelené, uvnitř červené :hahaa: 174 | 175 | - kvalita testů lze oveřit mutačním testováním. Do aplikace zavedeme defekty (mutací zdrojového kódu, lze automatizovat třeba negací operátoru, off-by-one, vynechání volání...) a sledujeme, kolik jich bylo odhaleno testy => pokud něco prošlo, může jít o kandidáta na další testy 176 | - některé situace jsou pro náš produkt rizikovější (lze odhadnout při analýze), než ostatní - na ty bychom se měli zaměřit při testování 177 | - vstupy testů vhodně rozdělujeme na kategorie (e.g. <0, 0, >0), z každé vybereme pár reprezentantů (abychom nemuseli testovat úplně každou hodnotu) 178 | - typy pokrytí testy jsme popsali v [pokrytí testy](#pokrytí-testy) 179 | 180 | - testování si můžeme usnadnit tím, že v systému modelujeme nevalidní stavy jako nereprezentovatelné (rust enum <3, builder pattern, stavový automat...) 181 | 182 | ### Pokrytí testy 183 | - Můžeme sledovat různá kritéria, pokrytí znamená, že danou cestou kódu prošel aspoň jeden test, metrika je obvykle v procentech 184 | - **line/statement coverage** - pokryté řádky/výrazy 185 | - **function coverage** - pokryté funkce/metody, jde o to, zda byla aspoň jednou zavolána 186 | - **branch coverage** - pokryté logické větve programu 187 | - **condition coverage** - každá boolean podmínka byla vyhodnocena jako true i false 188 | - mnohdy není 100% pokrytí možné (pokud třeba někde něco reduntantně testujeme, better be safe than sorry) a zároveň 100% pokrytí neznamená bezchybnost 189 | - některé části kódu je mnohem těžší pokrýt, než jiné 190 | - může pomoct hledat části kódu, které jsou neotestované, ale o kvalitě testů se toho moc nedozvíme 191 | 192 | ### Jednotkové (unit) testy 193 | - validace, že se izolovaná jednotka kódu (funkce/třída) chová tak, jak bychom očekávali 194 | - white box 195 | - testy jsou automatizované, rychlé, jednoduché, čitelné, deterministické, každý testuje jednu jedinou věc 196 | - izolujeme jednotku od zbytku systému pomocí *test double*s, nafejkovaných závislostí 197 | - dummy objekt - nikdy se nepoužije, ale je potřeba třeba jako parametr 198 | - fake objekt - jen pro účelý testů, jednoduchý, ale v praxi nepoužitelný (e.g. in-memory db) 199 | - stub - vrací vždy stejnou věc 200 | - spy - je schopen si zapamatovat, jak a s čím byl volán (e.g. volala se metoda odeslání mailu s tímto obsahem) 201 | - mock - předprogramovaný objekt (když tě někdo zavolá s parametrem A, uděláš toto, jinak něco jiného) 202 | - *AAA*, arrange (příprava), act (provedené testovaného chování), assert (ověření) - tři fáze každého testu, act by měl být co nejkratší 203 | - e.g. cargo test, jest, junit 204 | - pokročilejší techniky zahrnující analýzu zdrojového kódu a následné vygenerování vstupních hodnot (symbolic execution), případně formální verifikace využívající matematických důkazů, model checking... 205 | 206 | ### Integrační testy 207 | - sledují, zda spolu jednotky interagují tak, jak bychom očekávali 208 | - pomalejší, větší a složitější, než unit testy 209 | - black/white box 210 | - pro testování UI použijeme *Playwright* (dřív se používalo *Selenium*) 211 | 212 | ### Systémové testy 213 | - ověření, že systém splňuje specifikované požadavky 214 | - testují použitelnost, kapacitu, výkon, splnění funkcionality, bezpečnost... 215 | - benchmarking, penetrační testování, uživatelské testy... 216 | - lze automatizovat pomocí programem ovládaným prohlížečem (Playwright, dříve Selenium, Puppeteer) 217 | - black box 218 | 219 | ### Akceptační testy 220 | - ověření, že systém splňuje business požadavky a je připraven k vydání 221 | - může být ve formě odškrtávání políček s požadavky na systém, které zákazník předem určil 222 | - prováděny se zákazníkem 223 | - black box 224 | 225 | 226 | ### Test-driven development (TDD) 227 | - skládá se z tří fází, red, green, blue, které iterativně aplikujeme. V každé části se snažíme docílit pouze jedné věci (a ničeho jiného, holt počkáme do další fáze) 228 | - **red/test** - vytvoříme failující test pro co nejmenší část funkcionality, kterou chceme implementovat. 229 | - **green/write** - implementujeme funkcionalitu co nejjednodušeji tak, aby test prošel (a zároveň nerozbil jiný test) 230 | - **blue/refactor** - upravíme implementaci tak, aby odpovídala standardům, aby byl kód hezký... 231 | 232 | ### Behaviour-driven development (BDD) 233 | - se zákazníkem sepíšeme chování systému jako jednotlivé scénáře 234 | - scénáře slouží vývojářům i testerům jako jednotky 235 | - e.g. gherkin, cucumber - konstrukty given, when a then (jako AAA) se používají pro definici scénářů v english-like jazyce srozumitelném zákazníkovi, tyto scénáře se pak objevují i v testech 236 | 237 | ## Ladění a testování výkonu 238 | 239 | Cílem je identifikace a řešení případných problémů týkajících se rychlosti, odezvy a propustnosti systému, nalezení hranic 240 | 241 | - **Load testing** 242 | - zátěžové testy, sledujeme jak systém zvládá dlouhodobější zátěž 243 | - **Stress testing** 244 | - sledujeme, jak se systém vypořádává s krátkodobými výkyvy v zátěži (když najednou přijde spousta požadavků) 245 | 246 | Běžící systém je také vhodné dlouhodobě monitorovat, abychom odhalili další slabá místa. 247 | 248 | Výkon lze obecně zvýšit za cenu dalších atributů (například maintainability), proto je nutné volit správný kompromis pro náš případ. 249 | 250 | e.g. Gatling, Siege, LoadRunner 251 | 252 | ## Proces řízení kvality ve vývoji softwarových systémů 253 | 254 | skládá se z 255 | - definice požadavků na sw kvalitu a plánování - specifikace funkčních i nefunkčních požadavků, stanovení hodnotících kritérií, rizik, určení metrik, podrobný popis a rozvržení aktivit k zajištění kvality 256 | - zajištění (assurance) sw kvality - definice a kontrola procesů, které povedou k zajištění sw kvality a prevenci defektů (mimo jiné nastavení CI/CD) 257 | - kontrola sw kvality - kontrola, zda produkt/jeho části splňují požadavky (včetně požadavků na kvalitu) a jejich vývoj se řídí definovanými procesy, monitoring zda se držíme procesů a vytyčených cílů 258 | - zlepšení kvality - snaha zlepšit procesy, abychom docílili zlepšení kvality 259 | 260 | ## Notes 261 | - **Capability Maturity Model** - definuje úrovně vyspělosti organizace v kontextu zajištění kvality 262 | - Level 1 Výchozí - chaos, nepředvídatelná cena, plán 263 | - Level 2 Opakovatelný - intuitivní, cena a kvalita jsou proměnlivé, plán je pod vědomou kontrolou, neformální metody & procedury 264 | - Level 3 Definovaný - orientace na kvalitu, spolehlivé ceny a plány, stále nepředvídatelný výkon systému kvality 265 | - Level 4 Řízený - měření, promyšlená a statisticky řízená kvalita produktu 266 | - Level 5 Optimalizující - automatizace a zlepšení výrobního procesu, prevence chyb, inovace technologie 267 | 268 | 269 | ### Prevence problémů kvality 270 | - následování best practices a konvencí, obecných (SOLID, clean code) i pro danou technologii/jazyk (eslint, cargo fmt) 271 | - využití principů návrhových vzorů 272 | - techniky jako TDD, párové programování, code reviews 273 | - použití procesních standardů (ITIL), agilních technik (scrum, kanban) 274 | - automatizované testování, CI 275 | - komunikace, jednotný jazyk 276 | - fail-fast přístup - snažíme se detekovat problém ve vstupech, namísto abychom klidně akceptovali cokoliv a pak se divili při neočekávaném chování 277 | - design by contract - naše metody (zvlášť při tvorbě) mohou vyžadovat splnění určitého kontraktu (lze vynutit asserty), aby mohly poskytnout garance o výstupech. Je možné použít podmíněnou kompilaci a mít kontrakty třeba jen ve vývojovém prostředí (tím se ale můžeme připravit o přesné určení místa problému na produkci) 278 | 279 | Nonfunkcionální problémy kvality se řeší architekturou. Pro prevenci těchto problémů je možné vytvořit model systému a na něm si simulačně ověřovat požadavky (e.g. schopnost obsloužit určitý počet požadavků za určitý čas) a případně odvodit nároky na jednotlivé komponenty (třeba maximální dobu zpracování požadavku v daném komponentu). 280 | 281 | Pro ověření kvality je také možné použít formální verifikaci (používá se třeba pro dokazování správnosti algoritmů). 282 | 283 | ### Detekce problémů kvality 284 | - code reviews (vzájemné mezi vývojáři), inspections (formální, je fajn použít formulář; ukazuje to přípravu, na nic se nezapomene a zároveň se odfiltrují zbytečnosti, nelpíme na stylu, řešíme správnost, dodržování standardů...) 285 | - (automatizované) testování (rust\cargo test) 286 | - statická analýza (rust\cargo clippy, borrow checker, sonarqube) - nespouštíme kód 287 | 288 | ### Špatný kód 289 | - pomíchané úrovně abstrakce 290 | - nízká koheze (megatřídy, dlouhé funkce..) 291 | - kruhové závislosti (je pak závislost na implementaci, blbě se sleduje flow a vztahy, blbě se to testuje, udržuje a škáluje) 292 | - duplikace kódu 293 | - spousta parametrů 294 | - blbé názvy 295 | - dělání věcí příliš "chytře", když to není nutné 296 | - nedodržování standardů/vhodných konstruktů jazyka 297 | - magické konstanty 298 | 299 | #### Code smells a řešení 300 | 301 | !Jednotlivé taktiky mohou být vzájemně v rozporu, je potřeba si určit, čeho chceme docílit! (e.g. udržitelnost vs výkon) 302 | 303 | - **Udržitelnost** 304 | - příliš brzké optimalizace => nejdřív profiluj, pak případně optimalizuj 305 | - přílišná flexibilita => snaž se o jednoduchost, pak případně rozšiřuj 306 | - snaha o moc chytré řešení => stavební základy by měly být co nejjednodušší 307 | - nepoužívání standardů, principů návrhových vzorů 308 | - nízká modularizace 309 | - **Výkonnost** 310 | - redundantní práce => kešování, memoizace, bottom-up approach dynamického programování 311 | - sekvenční zpracování/hledání => binární hledání, chytřejší algoritmy, práce se seřazenými kolekcemi, paralelizace go brrrrrr 312 | - dlouhé kritické sekce (ve vícevláknových programech) => minimalizujeme kritickou sekci, může být lepší použít vícero zámků 313 | - aktivní čekání => async zpracování, necháme se notifikovat až operace skončí.. 314 | - **Spolehlivost** 315 | - nevalidujeme vstupní data, slepá důvěra 316 | - špatný error/exception handling 317 | - nepředpokládáme, že by funkce mohl někdo zavolat v jiném pořadí 318 | - přílišný hypetrain, používáme technologie, kterým úplně nerozumíme 319 | - absence logování => loguj, je fajn vědět, co se v systému dělo před pádem 320 | - snadný pád celého systému kvůli jedné části => nasaď více služeb, implementuj restart/recover, automatické přepnutí se na jinou, funkční službu 321 | - **Testovatelnost** 322 | - globální stav, proměnné 323 | - schovávání závislostí; je lepší provést dependency injection, než sázet na předchozí volání `init()` funkce pracující s globálním stavem 324 | - komunikace mezi jednotkami, které by neměly komunikovat => SOLID 325 | - nutnost hacky solutions, abychom vůbec mohli testovat => SOLID 326 | - nedeterminismus (závislost na čase, náhodnosti, globálním stavu, databázi... e.g. bacha na iteraci přes rust std::collections::HashMap, elementy jsou náhodně seřazené) 327 | - neoddělujeme inicializační a aplikační logiku 328 | - **Škálovatelnost** 329 | - monolitická aplikace, distribuce může zvýšit výkon/kapacitu, ale bacha na nutný režijní overhead, těžší testování, nasazování, bezpečnost... 330 | 331 | ### Sledování problémů kvality 332 | - issue tracking 333 | - správa technického dluhu (tracking, vyhrazení času na jeho nápravu) 334 | -------------------------------------------------------------------------------- /1_programovani_a_softwarovy_vyvoj.md: -------------------------------------------------------------------------------- 1 | # 1. Programování a softwarový vývoj. 2 | 3 | > Vývoj softwarových řešení, specifika implementace webových informačních systémů. Nástroje a prostředí pro softwarový vývoj rozsáhlých systémů. Základní koncepty softwarových architektur z pohledu implementace. Vícevrstvá architektura moderních informačních systémů, architektura model-view-controller. Persistence, ORM. Příklady z praxe pro vše výše uvedené. (PA165 || PV179) 4 | 5 | [PA165 Enterprise Java](https://is.muni.cz/auth/el/fi/jaro2021/PA165/um/) 6 | 7 | [PV179 Systémy v .NET](https://is.muni.cz/auth/el/fi/podzim2022/PV179/) 8 | 9 | 10 | ## Vývoj softwarových řešení 11 | - Vývoj sw řešení se obvykle skládá z kroků: 12 | 13 | - Analýza 14 | - Návrh 15 | - Implementace 16 | - Testování 17 | - Nasazení 18 | 19 | Více v otázce [Softwarové inženýrství](./3_softwarove_inzenyrstvi.md) 20 | 21 | - Klíčové je zajistit pravidelnou a dobře definovanou komunikaci mezi stakeholdery (nejen na začátku, ale i v průběhu vývoje), definovat ubiquitous language (univerzální jazyk domény) a vynucovat jeho používání, aby v rámci úzce spolupracujících skupin nedocházelo k vytváření vlastních výrazů a následnému neporozumnění mezi skupinami. 22 | 23 | - Při vývoji se často používá kontinuální integrace a nasazení (CI/CD), čímž se mohou vynucovat standardy (dobré pro udržitelnost kódu) a spouštět se automatizované testy. Bývá součástí verzování kódu. 24 | 25 | - klíčovou součástí analýzy a návrhu bývá dekompozice (a abstrakce) na komponenty, při které dělíme komplexní systém na jednodušší nezávislé části, abychom nemuseli neustále držet v hlavě kontext celého systému. Cílem je minimalizovat závislost mezi komponenty a dodržovat SOLID principy. [Více v Kvalita kódu](./2_kvalita_kodu.md). 26 | 27 | - komponenty systému mají dobře definovaný kontrakt, nezávisí na konkrétních implementacích, ale na abstrakcích (e.g. parametr metody je typu interface, ne konkrétní struktura) 28 | 29 | ## Specifika implementace webových informačních systémů 30 | 31 | - Webové informační systémy se obvykle skládají z několika částí: 32 | 33 | - **Uživatelské rozhraní/frotnend/klient** je zpřístupněno uživateli skrz prohlížeč. Základními stavebními kameny jsou HTML, CSS a JavaScript/Web Assembly. Tradičně šlo o **multipage aplikace** renderované na serveru (šablonovací systémy jako python\jinja, rust\askama, php má šablonování přímo v sobě), po každém požadavku proběhlo překreslení. Nedávno byl trend **singlepage** aplikací renderovaných na klientovi (založeny na JS frameworcích jako React, Vue, Svelte, Solid, nebo WASM (aktuálně defaultně) rust\yew), kde po iniciálním načtení aplikace putovaly mezi klientem a serverem jen data. Aktuální trend je používat fullstack/meta frameworky (NextJS, SvelteKit, rust\leptos...), kde prvotní vykreslení je na serveru a následně se web chová jako SPA (ale umožňuje vícero modů fungování, třeba plně static-site generation). Toto platí zvlášť pro menší projekty, protože fullstack framework umožňuje vývoj frontendu i backendu na jednom místě. 34 | - **Aplikační server/backend** slouží k vykonávání aplikační logiky, zpracovává požadavky klienta a odpovídá na ně, zajišťuje autentizaci a autorizaci. Stav systému propisuje do databáze, obvykle je server bezstavový. Použávají se general-purpose programovací jazyky (Rust, JS/TS, Go, C#, Python, Java). 35 | - **Databáze** uchovává stav systému. Tradičně se používá relační databáze (Postgres, MySql, Oracle), ale může být vhodnější použít dokumentovou (MongoDB) či grafovou (Neo4j). 36 | 37 | Webové informační systémy mají tyto specifika: 38 | - **snadnost aktualizací klienta**, na rozdíl od desktop aplikací není potřeba ze strany uživatele nic explicitně stahovat a instalovat 39 | - nutnost **responzivního a přístupného uživatelského rozhraní**, ke kterému uživatelé mohou přistupovat i z mobilních zařízení, prohlížeče usnadňují implementaci přístupnosti (vada zraku, přístup pouze pomocí klávesnice...) 40 | - většinou **tenký klient**, aplikační logika se provádí z pravidla na serveru. 41 | - webové systémy bývají (pokud není řešeno jinak) přístupné z celého internetu, proto je důležité vhodně řešit **autentizaci a autorizaci**, a jejich **zabezpečení proti útokům** (například SQL injection, XSS, CSFR, více níže). 42 | - mohou být používané větším množstvím uživatelů, proto je vhodně třeba řešit škálování (vertikální větším výkonem nemusí stačit, horizontální vícero stroji nemusí být vždy aplikovatelné). Aplikační servery je možné díky jejich bezstavovosti škálovat horizontálně, databáze se obvykle řeší vertikálně, či použitím distribuované databází (Cassandra). Základem zvyšování výkonu systému je kešování (Redis). 43 | - Obvykle se používá model klient-server 44 | 45 | ### Útoky 46 | - **SQL injection** do vstupního pole vložíme specifický string, který dokáže způsobit akci v databázi (e.g. vstup `ahoj; DROP TABLE Users; --`) 47 | - obrana pomocí prepared statements 48 | - **Session hijacking** útočník se zmocní cookie/tokenu, který se používá pro prokázání identity. Tokeny ukládáme jako cookie (nejbezpečnější, pro mobilní aplikace je v pohodě local storage) 49 | - obrana pomocí nastavení cookie jako "Secure" (lze poslat jen skrz https) a "HttpOnly" (nelze číst/upravit pomocí JS) 50 | - **Cross site scripting (XSS)** - útočník vloží na web obsah, který je validní html/js a oběti se zobrazí/spustí při načtení stránky. 51 | - obrana pomocí sanitizace vstupů 52 | - **Cross site request forgery (CSRF)** - útočník připraví a pošle klientovi URL odkaz (nebo vytvoří na svém webu formulář) vyvolávající akci na našem serveru. 53 | - obrana pomocí CSFR náhodných tokenů (jednorázově vydaný s požadavkem dávající uživateli přístup k akci). Token vložíme do formuláře (aby ho uživatel mohl odeslat) a zároveň si ho buď uložíme, nebo ho nastavíme jako cookie. Při zpracování požadavku zkontrolujeme, zda se tokeny shodují. 54 | - obrana pomocí cookie atributu "SameSite", který modifikuje, kdy se cookie posílá při cross-site požadavcích. `Strict` neposílá cookie nikdy při cross site požadavcích, `Lax` jen při GET požadavcích - ty by stejně neměly vyvolávat akci, takže by to nemělo vadit. Problém však přetrvává u starých prohlížečů, nebo pokud se útočníkovi podaří umístit vlastní formulář na naši doménu či subdoménu. 55 | - obrana pomocí explicitního potvrzení (nebo MFA) u důležitých akcí 56 | - **Clickjacking** útočník na svém webu zobrazí průhledný ifame nad svou stránkou. Uživatel si myslí, že kliká na tlačítko útočníkova webu, ale ve skutečnosti kliká na web v iframe, čímž může vyvolat nechtěnou akci 57 | - obrana pomocí `X-Frame-Options` hlavičky 58 | - **Phishing** útočník vytvoří vizuálně identický web, na kterém chce po uživatelích přihlášení 59 | - obrana pomocí kontroly domény uživatelem, nutný trénink uživatelů 60 | - pomoct může přizpůsobení webu - pokud je uživatel zvyklý vídat u kritických akcí svou fotku a všimne si, že na útočníkově webu chybí, může pojmout podezření 61 | 62 | ### Auth 63 | Více v [Bezpečný kód](./dev_3_bezpecny_kod.md) 64 | 65 | #### Autentizace 66 | 67 | - ověření identity 68 | - **Session based** - uživatel poskytne údaje, server vydá cookie, kterou si udržuje (db/paměť). Uživatel následně s každým požadavkem zasílá cookie, podle které server ověří a rozpozná uživatele 69 | - **Token based** - uživatel ověří svou identitu, server zapouzdří údaje o uživateli do tokenu, který podepíše, čímž zajistí, že je možné detekovat modifikaci. Uživatel následně zasílá token, kterým prokazuje svou totožnost, mohou zde být i informace o právech. Na rozdíl od sessions nemusí díky certifikátům servery nic držet v paměti, jde o řešení vhodné pro použití s vícero servery/systémy, nebo když se uchovávají sessions v databázi a databáze začíná být bottleneck. Tokeny se nedají revokovat ze strany serveru => dává se časově omezená platnost 70 | - pokud nám nevadí používat autorizaci poskytnutou střetí stranou, bývá nejbezpečnější a nejjednodušší řešení použít federalizovanou identitu. Pokud opravdu chceme ukládat uživatelská hesla, ukládáme heše (se solí) získané aktuálně doporučovaným Argon2 (může se změnit). 71 | 72 | #### Autorizace 73 | 74 | - ověření práv k určité akci 75 | 76 | ### Používané technologie 77 | 78 | - **HTTP basic** - http header `Authorization: Basic `, kde `` jsou `:` v base64 79 | - `-` hlavička je viditelná (=> použij aspoň https), údaje se zasílají s každým požadavkem 80 | - **TLS certifikáty** - server musí poskytnout certifikát, klient může poskytnout certifikát, čímž se autentizuje 81 | - **OAuth2** - protokol pro poskytnutí autorizace třetím stranám, funguje na principu vydávání tokenů (Refresh token, Access token). Access token má omezenou dobu platnosti a obsahuje autorizační data (majitel tokenu je oprávněn k akci) uživatele podepsanou soukromým klíčem autorizačního serveru. Refresh token může mít delší dobu platnosti, je uložený u uživatele a je možné ho použít k získání dalšího access tokenu bez nutnosti autentizace (provedou se ale kontroly ohledně práv uživatele). 82 | - **OpenID Connect** - nadstavba nad OAuth2, přidává autentizaci a informace o identitě uživatele. Používá se pro federalizovanou správu identity (single sign-on). *Klient* je aplikace, která potřebuje autentizovat uživatele. *Autorizační server* autentizuje uživatele, vydává token autorizující držitele k přístupu ke *scopes* obsahující *claims* (e.g. scope profil pro claimy id, email, name, picture, locale...) umístěných na *resource serveru*. Resource server slouží jako endpoint pro poskytování claimů na základě scopes v tokenu 83 | - **SAML** - xml protokol pro výměnu autentizačních a autorizačních dat, starší než oauth/oidc 84 | - **Kerberos** - na rozdíl od oauth2 a openid connect používá v základu symetrickou kryptografii (e.g. uživatelovo heslo je na autorizačním serveru, uživatel posílá pouze svou identitu a server vrací přístupová data šifrovaná heslem uživatele) 85 | 86 | ## Nástroje a prostředí pro softwarový vývoj rozsáhlých systémů 87 | Pro vývoj rozsáhlých systémů se používají následující typy nástrojů 88 | 89 | - **Editory a vývojová prostředí** v ideálním případě (pokud jazyk podporuje Language Server Protocol) zavisí na preferencích vývojáře. Je možné použít od jednoduchých editorů až po plně integrovaná vývojová prostředí (vim/neovim, vscode, jetbrains produkty). 90 | - **Verzovací systémy** umožňují správu verzí zdrojového kódu a spolupráci vývojářů (git, SVN). Obvykle běží na platformě, která může být hostovaná (github, gitlab), nebo kterou si hostujeme sami na vlastních serverech (gitlab). Platformy obvykle nabízí víc, než jen správu zdrojového kódu (CI/CD, issue tracking..) 91 | - **Nástroje pro správu projektů** slouží pro správu úkolů, sledování chyb a komunikaci v týmu (Clickup, Jira, ale i třeba Github). 92 | - **Nástroje pro testování** umožňují vytvářet a spouštět testy, simulovat uživatelské interakce, ověřovat funkčnost systému (Jest, cargo test, Insomnia, Postman) 93 | - **Nástroje pro kontinuální integraci a nasazení** automatizují spouštění testů a sestavení výsledného produktu (github workflows, gitlab CI/CD, circle ci, Travis CI, Jenkins). 94 | - **Monitoring a logování** slouží pro sledování výkonu systému a analýzu chyb a problémů (Grafana) 95 | - **Dokumentační nástroje** popisující fungování systému a jeho částí. Dokumentaci zdrojového kódu je vhodné z něj generovat, aby se minimalizoval problém neaktuálnosti (cargo doc, OpenAPI (machine-readable JSON/YAML formát, je možné ho generovat z anotací, nebo z něj generovat příklady, dokumentaci), pro jednoduchý formátovaný text Markdown). Dokumentace je důležitá zvlášť pro vystavované API 96 | - **Kontejnerová prostředí** slouží pro minimalizaci rozdílů mezi prostředími, usnadňují reprodukovatelnost, ve kterých aplikace běží (vývojové, testovací, produkční) (Docker, Podman). 97 | - **Nástroje pro analýzu kódu** kontrolují dodržování standardů, zajišťují určitou kvalitu kódu, hledají potenciální chyby/slabá místa (cargo clippy, ESLint, SonarQube). 98 | 99 | ## Základní koncepty softwarových architektur z pohledu implementace, Vícevrstvá architektura moderních informačních systémů, Architektura model-view-controller 100 | 101 | - **MVC pattern - model, view, controller** - odděluje systém na model, view a controller. Model obsahuje data a business logiku. View je zobrazením těchto dat a controller slouží k manipulaci nad modelem. Jde o cyklický vztah: --> 102 | 103 | `USER (uses)> CONTROLLER (manipulates)> MODEL (updates)> VIEW (shown to)> USER` 104 | 105 | - oddělení logiky zvyšuje modulárnost kódu, který je pak snadnější upravovat, testovat, udržovat 106 | - e.g. multipage web 107 | - **MVP pattern - model, view, presenter** - presenter je prostředník mezi modelem a view, jde přes něj veškerá komunikace. Uživatel používá pouze view, akce uživatele view předává presenteru, který aktualizuje model a zasílá view nová data. E.g. SPA 108 | - **MVVM pattern - model, view, view model** - uživatel interaguje pouze přes view, veškerá komunikace jde přes view model, které provádí data, propisuje je do modelu. Rozdíl oproti mvp je, že view model může být použit pro vícero views, změny se sledují pomocí observeru. E.g. android aplikace. 109 | 110 | - **Klient-Server** - klient slouží jako uživatelské rozhraní. Server zpracovává požadavky zasílané klientem a odpovídá na ně. Server dle požadavku klienta provádí aplikační logiku, přistupuje k databázi... Komunikace je vždy iniciována klientem, server pouze odpovídá. Lze dělit na úrovně (2 tier, 3 tier i s databází, další úrovně můžou být servisní vrstvy...) 111 | 112 | - **Peer-to-Peer** - každý klient je současně i serverem, klienti spolu komunikují napřímo. Klienti takto sdílí výpočetní výkon, distribuují data... e.g. BitTorrent 113 | 114 | - **Vrstvená architektura (layered, případně clean)** - Dělí monolitický systém na vrstvy, každá je zodpovědná za určitou část aplikace. Vrstva využívá služeb vrstvy pod ní. Každá vrstva může být otevřená/uzavřená, otevřené vrstvy je možné přeskočit. 115 | - **Presentation** - closed, UI, klient 116 | - **Business** - closed, zpracovává business logiku 117 | - **Service** - open, obsahuje sdílené komponenty business vrstvy (autentizace, logování) 118 | - **Persistence** - closed, slouží k přístupu do databáze, repository pattern () 119 | - **Database** - closed, čistě databázová vrstva 120 | 121 | - jednoduchá na vývoj (pořád je to monolit), levná, vhodná pro projekty s velmi omezeným časem/rozpočtem, vhodná pokud si nejsme jistí co použít 122 | - oproti klasickému monolitu je větší overhead s předáváním dat mezi vrstvami 123 | - není odolná vůči chybám, pád části = pád celého systému, relativně dlouhý startup 124 | - vrstvu je možné nasadit samostatně a zlepšit tak škálovatelnost systému 125 | - e.g. eshop 126 | 127 | - **Pipeline architektura/Pipes and Filters** - monolitická, funguje na principu MapReduce, skládá se z 128 | - **pipe**, point-to-point komunikace 129 | - **filter**, komponenty transformující data, bezstavové, ale mohou zapisovat do db. Filter se má soustředit čistě na jednu úlohu. Jsou typy 130 | - **Producer/source** - zdroj, iniciátor akce 131 | - **Transformer (map)** - transformuje vstup na výstup 132 | - **Tester (reduce)** - testuje kritérium a potenciálně vyprodukuje (mimo předání dat bez modifikace dál) výstup, který může vyvolat akci (zápis do datbáze) 133 | - **Consumer/sink** - ukončuje akci 134 | - filtry je možné snadno používat znovu (reuse) 135 | - vede k batch processingu, což není fajn pro rychlou odezvu systému 136 | - e.g. unix terminal, compiler 137 | ![](img/20230518144835.png) 138 | 139 | - **Microkernel/Hexagonal/Component-based architecture** - monolitická, dělí systém na jádro (core) a (ideálně) plug-in komponenty, aplikační logika je v těchto komponentech. Jednoduchá rozšiřitelnost, adaptabilita, customizace 140 | - Jádro obsahuje minimální nutnou funkcionalitu, která se rozšiřuje skrz pluginy 141 | - Pluginy by měly být nezávislé, připojitelné za běhu, mohou mít vlastní db, mohou být vzdálené a komunikovat s jádrem přes e.g. REST. 142 | - Pluginy jsou obvykle dostupné z nějakého registru, kde jsou data jako název, kontrakt, detaily pro připojení pluginu. 143 | - Důležité je dobře definovat standardizované kontrakty, které musí pluginy splňovat 144 | . pro využití komponentu je nutné řešit discovery pomocí nějakého registru (může stačit hashmapa), musíme znát identitu (která by se neměla měnit) chtěného komponentu, který v systému nemusí být 145 | 146 | - e.g. VS Code - jádro je textový editor, pluginy jsou extensions 147 | 148 | - **Servisně orientovaná architektura (SOA)** - hybrid mezi monolitem a microservices. 149 | - separátní UI (může jich být více), separátně nasazené služby (obvykle 4-12), každá se soustředí na jednu úlohu (nebo část systému), sdílená db, služby jsou interně tvořeny vrstvenou architekturou/děleny dle domény 150 | - Pokud služba využívá část databáze, kterou žádná jiná služba nevyužívá, je možné tuto část oddělit do vlastní databáze. 151 | - pokud chceme jednotné API, používá se vrstva fasády, která přeposílá komunikaci jednotlivým službám 152 | - ACID transakce (microservices mají BASE, basically available, soft state, eventually consistent, i.e. duplikace dat, konzistence může chvíli trvat..), fajn pro konzistenci a integritu, ale úprava znamená nutnost testu celého systému 153 | - fajn pro domain driven design bez přílišné složitosti 154 | - fajn když potřebujeme ACID 155 | 156 | - **Microservices** 157 | - cílem je vysoká nezávislost jednotlivých služeb, mohou být implementovány v různých programovacích jazycích 158 | - každá služba se stará o nutné minimum, služby fungují nezávisle 159 | - nesdílí se DB 160 | - duplikace je akceptovatelná, když se sníží provázanost 161 | 162 | ## Persistence, ORM 163 | - zabývá se uchováním dat mezi jednotlivými běhy aplikace/restarty systému/požadavky klienta 164 | - **Relační databáze** - nejběžnější způsob uchovávání data v sw systémech. Data jsou strukturována do tabulek obsahující sloupce, řádek tabulky = datový záznam. Vztahy mezi daty se řeší relacemi, odkazy na primární kíč jiné tabulky. Pro manipulaci nad daty se využívá SQL (structured query language). (Postgres, MySql, Sqlite). Jsou široce podporovány v programovacích jazycích, je potřeba dávat pozor na sql injection (rust/sqlx). Při použití SQL v aplikacích se doporučuje použít Repository/DAO pattern, případně CQRS. 165 | - **Objektově relační mapování (ORM)** umožňuje mapování objektového modelu aplikace na relační databázi. Výhodou je, že není nutné psát přímé SQL dotazy a kód je (měl by být) agnostický k použité databázi, může však vzniknout problém s neodstatečnou kontrolou nad dotazem/nutností tvorby specializovaných struktur/tříd. Složitější dotazy mohou být ve výsledku podobně komplikované, jako vlastní sql dotaz. Problém může působit i výkon (js\prisma, rust\diesel, java\hibernate) 166 | - **Souborový systém** - data je možné ukládat přímo do souborového systému. Toto je vhodné třeba pro obrázky/pdf, ale je potřeba ošetřit, abychom neposkytli přístup k jiným částem systému, než k jakým chceme. 167 | - **NoSQL** - alternativa k relačním db, umožňují ukládání a manipulaci s nestrukturovanými daty. Oproti relačním databázím poskytují lepší škálovatelnost a flexibilitu, problém může být konzistence (často se používá duplikaci pro vyšší rychlost) (mongodb, cassandra) 168 | - **Cachování** -dočasné ukládání často používaných dat/výsledků operací. Lze provádět na úrovni RAM, před databází, před serverem... (redis, nginx) 169 | 170 | ## Notes 171 | 172 | **Validace** - systém dělá to, co se od něj čeká (v rámci požadavků) 173 | 174 | **Verifikace** - systém dělá věci správně interně 175 | 176 | **DAO** - data access object, abstrahuje přístup k databázi/persistenčnímu mechanismu 177 | - umožňuje výměnu persistenční technologie, aniž by bylo třeba zasahovat do jiných vrstev 178 | - usnadňuje testování business logiky 179 | - obvykle jeden na entitu, CRUD 180 | 181 | **DTO a.k.a. Value Object** - data transfer object, zapouzdřuje data pro komunikaci mezi vrstvami 182 | 183 | **Inversion of Control** - struktura má pole (třeba connection pool), které používá pro své fungování (závisí na něm). Nemá si pole tvořit sama, naplnit ho z parametru konstruktoru/jiným způsobem. 184 | 185 | **Dependency Injection** - existují frameworky, které asistují s IoC pomocí injekce závislostí přímo do polí struktur "automaticky" (rust\di, java\spring) 186 | 187 | **Aspect Oriented Programming** - technika, kde se definuje aspekt, který je volán pokaždé definované akci. E.g. pro logování - aspekt je definován jednou a je řečeno, že se má provádět pro všechny metody. Není nutné upravit každou metodu, aby explicitně logovala. 188 | 189 | **Software as a service**, **Platform as a service** (staráme se jen o vývoj, vše ostatní zajišťuje služba, e.g. Heroku), **Infrastructure as a service** (pronajímáme si infrastrukturu, e.g. klasický cloud, AWS, azure, gcp...) 190 | 191 | **CORS** - zabraňuje, aby skript z prohlížeče komunikoval se serverem odjinud, než z webové aplikace. E.g. pokud z klienta SPA myweb.com chci poslat asynchronní dotaz (pomocí fetch API) na other.com, tak pokud other.com explicitně nepovolí přístup, prohlížeč můj požadavek neodešle. 192 | 193 | **Message queue** - namísto synchronního zpracování je možné použít message queue (používá se často interně v distribuovaných systémech, není nutné okamžité zpracování, usnadňuje load balancing, je možný broadcast, zprávy mohou být persisted, ...) (apache kafka - byť je spíš event broker, rabbit mq). 194 | Možné problémy: 195 | - delay/blížíme se plné frontě (=> flow control) 196 | - cíl doručení není dostupný a je důležité doručit (=> ulož do error queue, aby bylo možné zprocesovat později/ručně) 197 | - zpráva dorazí vícekrát (=> služby dělej idempotentní). 198 | 199 | Obecně dokumentuj možné nestandardní chování a způsoby řešení problémů, měj recovery mechanismy. 200 | 201 | Queue (musí se doručit aspoň jednomu) vs Topic (publisher-subscriber model). 202 | 203 | **Continuous integration** - pravidelně sestavujeme výsledný systém (děláme malé a relativně jednoduché změny), automaticky testujeme výsledek 204 | 205 | **Continuous delivery** - pravidelně sestavujeme výsledný systém tak, že by mohl být okamžitě vydán, automaticky testujeme výsledek 206 | 207 | **Continuous deployment** - pravidelně dodáváme, automaticky testujeme výsledek 208 | 209 | **Regresní testy** - provádí se po změnách, abychom detekovali nechtěné efekty 210 | 211 | #### REST (Representational State Transfer) 212 | - nejpoužívanější styl/způsob tvorby rozhraní webových aplikací (ne protokol), vychází z HTTP, požadavek má syntax ` ` 213 | - zdroje identifikovány URI, mohou mít různou podobu (JSON, XML, HTML, PNG...) 214 | - užívá HTTP metod 215 | - **GET** - pro získání dat 216 | - **HEAD** - pro získání metadat - hlavička je totožná s GET, ale v odpovědi není přítomno tělo 217 | - **POST** - požadavek, aby cílový zdroj zpracoval data obsažená v těle. Obvykle se používá pro akce/přidání nového prvku do kolekce (login, přidání příspěvku...). V případě tvorby prvku bývá pravidlem vrátit nově vytvořené ID v odpovědi 218 | - **PUT** - jako post, ale součástí požadavku je ID. Prvek s tímto ID má být upraven novými daty (v těle), nebo vytvořen právě s tímto ID 219 | - **PATCH** - jako put, ale v těle nemusí být všechna pole upravovaného prvku - změnit se mají jen ta pole, která jsou přítomná 220 | - **DELETE** - požadavek k odstranění dat 221 | - dále existují **CONNECT**, **OPTIONS** a **TRACE** 222 | 223 | *safe* metody nemění stav na serveru (get, head, options, trace) 224 | 225 | *Idempotentní* metody splňují vlastnost, že vícero identických požadavků má stejný efekt, jako jediný požadavek (všechny, kromě POST, PATCH (není zcela standardizované chování) a CONNECT) 226 | 227 | RESTové služby jsou bezstavové (pro vyhodnocení požadavku by nemělo být nutné znát nic, co není v požadavku obsazeno, e.g. namísto `GET /nextPage` se použije `GET /pages/2`) 228 | 229 | Některé REST metody jsou kešovatelné, v komunikaci mohou být prostředníci (třeba cache, proxy, load balancer..), o kterých klient neví 230 | 231 | **Best practices** 232 | - konzistentní pojmenovávání zdrojů 233 | - vztahy řešíme pomocí URI (e.g. `GET /users/1/orders` vrací objednávky uživatele 1) 234 | - je v cajku udělat alias (e.g. `/me`, `/trends`) 235 | - používání správných metod, přemýšlíme v rámci CRUD operací 236 | - filtrování a řazení řešíme pomocí query parametrů (`/users?active=true&sort=name`) 237 | - verzování API 238 | - metody, které vytvářejí/upravují zdroje by měly vracet výslednou podobu zdroje 239 | - aktuálně je preference pracovat s JSON 240 | - používání správných HTTP návratových hodnot 241 | 242 | #### HATEOAS (Hypermedia as the engine of application state) 243 | - jakýkoliv zdroj (URI) vrácený serverem může být předmětem další komunikace 244 | - k entitám přidáváme href 245 | 246 | #### WSDL (web services definition language) 247 | - standardizovaný způsob popisu rozhraní webových služeb (jméno, lokaci, podporované protokoly, operace, formát zpráv..), používá se se SOAP 248 | 249 | #### SOAP (simple object access protocol) 250 | - komunikační protokol pro web services, umožňuje výměnu dat, vzdálená volání funkcí 251 | - slouží jako jednotná vrstva mezi službami (aktuálně se používá spíš gRPC) 252 | 253 | #### Java specifické věci 254 | 255 | **Servlety** jsou komponenty umožňující zpracování požadavků a zaslání odpovědi (a.k.a. handler). 256 | 257 | **Java Web Containers** poskytují servletům runtime a starají se o další věci (e.g. sessions), může v nich běžet vícero web aplikací ve WAR (web archive). Alternativně je možné použít lehčí variantu, e.g. spring boot 258 | 259 | **Java Server Pages** umožňují psát javu do html (server-side), obdobně jako php 260 | -------------------------------------------------------------------------------- /6_pocitacove_site.md: -------------------------------------------------------------------------------- 1 | # Počítačové sítě 2 | 3 | > Koncepty, principy, architektury. ISO/OSI a TCP/IP model, IP protokol, transportní protokoly (TCP, UDP). Protokoly na síťových vrstvách, funkce IPv4, pokročilé funkce IPv6. Peer-to-peer (P2P) sítě, ad-hoc/senzorové sítě, vysokorychlostní sítě, počítačové sítě a multimédia. Příklady z praxe pro vše výše uvedené. ([PA159](https://is.muni.cz/auth/el/fi/podzim2022/PA159/um/), PA191) 4 | 5 | ## Koncepty, principy, architektury. 6 | 7 | > Počítačová síť je skupina počítačů a zařízení, propojená komunikačními kanály, která umožňuje komunikaci uživatelů sítě a sdílení prostředků (informací, souborů, dat, sw, hw). 8 | 9 | Ideální síť je transparentní (uživatel si ani nevšimne, že komunikuje skrz síť), s neomezenou propustnostní, bezztrátová, bez latence, zachovávající pořadí paketů. V reálu sítě takovéto problémy a limitace mají. 10 | 11 | Zákadní typy sítí 12 | - **Connection-oriented (propojované)** - pro komunikaci se stanoví/vyhradí kapacita, která není využívaná nikým jiným (e.g. dřívější drátový telefon), snadno se zajišťuje kvalita služeb, v QoS tomu odpovídají integrované služby 13 | - **Connection-less (paketové)** - kapacita využívána všemi komunikujícími, komunikátoři své zprávy dělí a balí na pakety, těžko se řeší kvalita služeb (e.g. Internet), v QoS tomu odpovídají diferenciované služby 14 | 15 | K stanovení jednotných pravidel a způsobu komunikace slouží standardizované **protokoly**. 16 | 17 | Architektury [peer-to-peer](./6_pocitacove_site.md#peer-to-peer-p2p-sítě) vs klient-server (klienti komunikují pouze se serveren, service discovery konfigurací klientů, klient iniciuje spojení) 18 | 19 | Směrování probíhá pomocí směrovacích tabulek routerů - na základě adresy (a případně typu) paketu se podle tabulky určí další směr, hop-by-hop princip. Další destinace se určuje na základě nejdelšího CIDR prefixu adresy. Směrovací jsou obvykle aktualizovány distribuovanými algoritmy. Na routerech je možné pakety filtrovat (zatoulané, k zajištění QoS) a případně klasifikovat (při modelech pay-as-you-go). Směrovat je možné nejen pomocí nejkratší cesty, ale i s ohledem na aktuální stav/vytíženost sítě. 20 | 21 | ## ISO/OSI, TCP/IP model 22 | 23 | ### ISO/OSI 24 | 25 | 7 vrstev, každá zodpovědná za určitou funkcionalitu, vrstva komunikuje pouze se svými sousedy, každá vrstva slouží jako abstrakce 26 | - **Aplikační** - síťová aplikace 27 | - **Prezentační** - reprezentace dat 28 | - **Relační (session)** - řešení uživatelsých relací (sessions) 29 | - **Transportní** - komunikace mezi procesy 30 | - **Síťová** - logické adresování v rámci sítě, routing 31 | - **Datalinková** - fyzické adresování (MAC) 32 | - **Fyzická** - drát, bity, signály... 33 | 34 | V praxi se ujal model TCP/IP, který jednotlivé vrstvy ISO/OSI slučuje. 35 | 36 | ### TCP/IP 37 | 38 | 4 vrstvy 39 | - **Aplikační** 40 | - poskytuje služby uživatelům (web, mail...) 41 | - používají se aplikační protokoly (HTTP, SMTP, DNS, FTP...), které jsou součástí aplikací, každý protokol definuje syntaxi, sémantiku, typy a pravidla výměny zpráv 42 | - rozlišujeme 43 | - peer-to-peer vs klient-server 44 | - pull (datový přenos iniciuje klient) vs push (datový přenos iniciuje server) model 45 | 46 | - **Transportní** - TCP, UDP 47 | - bere **data**, transformuje je na **segmenty** 48 | - zajištění transportu segmentů do cílové aplikace, komunikace mezi procesy 49 | - adresování pomocí portu (16 bitové číslo 0-65535) 50 | - může poskytovat end-to-end spolehlivost, spojení (segmenty jsou číslovány, záleží na pořadí, dodání je potvrzeno) 51 | - může poskytovat kontrolu spojení, quality of service 52 | - logický komunikační kanál, iluze přímé komunikace 53 | 54 | - **Síťová (internet layer)** 55 | - IP (internet protocol) 56 | - bere **segmenty**, transformuje je na **pakety** (= datagramy) 57 | - zajišťuje přenos paketů mezi komunikujícími uzly (i napříč různými LAN), čímž de facto vytváří WAN 58 | - umožňuje adresování každého zařízení na internetu pomocí IP adresy (IPv4 32 bitů, IPv6 128 bitů) 59 | - zajišťuje směrování paketů - závisí na vytíženosti sítě a její topologii 60 | - topologie celého internetu se těžko určuje, dynamicky se mění 61 | - každý router řeší doručení paketu na své nejbližší sousedy ve snaze doručit paket blíže (domnělému) cíli na základě své **směrovací tabulky** 62 | - upravována manuálně (vhodné pro malé sítě), nebo automaticky pomocí distribuovaných algoritmů 63 | - **Distance Vector** 64 | - *vše co vím řeknu svým sousedům* 65 | - protokol **RIP** 66 | - sousedící routery si periodicky/při změně vyměňují směrovací tabulky ve kterých jsou informace o vzdálenostech (hop distance) k různým cílům (distance vector), princip [Bellman-Ford](https://www.youtube.com/watch?v=obWXjtg0L64) algoritmu 67 | - používaný pro malé sítě, kde není redundance 68 | - dále se používají IGRP, EIGRP 69 | - **Link State** 70 | - *všem řeknu informaci o svých sousedech* 71 | - routery si vyměňují informace o stavu svch sousedů, je uchovávána topologie celkové sítě, každý si dopočítá svou routovací tabulku, pro cesty se používá [Dijkstra](https://www.youtube.com/watch?v=_lHSawdgXpI). 72 | - protokol **OSPF**, open shortest path first 73 | - metrikou (výhou hrany) je cena odvozená od šířky pásma, nižší je lepší 74 | - robustnější, protože si každý počítá routing tabulky sám 75 | - používaný pro velké sítě 76 | - dále se používá IS-IS 77 | - **Path Vector** 78 | - distance vector, ale vyměňují se nejen ceny cest, ale celé jejich popisy 79 | - protokol **BGP (Border Gateway Protocol)**, umožňuje routing pravidla (policies), používá CIDR na zefektivnění routování 80 | - používá se pro směrování mezi autonomními systémy 81 | - je možné použít interní (RIP, OSPF) pro naši doménu (autonomní systém) a externí routing (EGP, BGP-4) pro směrování mezi doménami (autonomními systémy) 82 | 83 | 84 | - **Vrstva síťového rozhraní (network access layer)** - často se tato vrstva ještě rozlišuje na 85 | - **datalinkovou** 86 | - bere **pakety**, transformuje je na **frame**y obsahující mimo jiné adresu odesílatele i příjemce (díky tomu se m.j. zařízení dozví, kdo na médiu komunikuje) 87 | - poskytuje adresování pomocí fyzických/MAC adres 88 | - zajišťuje spolehlivost fyzické vrstvy (detekce chyb & případná korekce, možné díky redundanci, e.g. paritní bit, Hammingův kód) 89 | - flow control 90 | - řeší koordinaci přístupu více zařízení ke sdílenému médiu (dělením na kanály, na základě rezervací, náhodnosti...) - MAC protokol 91 | - na této úrovni lze zapojovat sítě do topologií (běžné topologie bus, hvězda, kruh) 92 | - **fyzickou** 93 | - poskytuje rozhraní ve formě **frameů bitů** 94 | - poskytuje přístup k přenosovému médiu, 95 | - interně vrstva transformuje bitu na signály přenosového média, zajišťuje synchronizaci, multiplexing (skloubení více signálů/datových toků do jednoho pro přenos na sdíleném médiu, časový/frekvenční/vlnovědélkový multiplexing), demultiplexing... 96 | - médiem může být drátový/optický kabel, vzduch (pro bezdrátový přenos, rádiové/infračervené signály...) 97 | 98 | 99 | ## IP protokol 100 | 101 | - Zajišťuje doručení IP datagramů (data rozřezané na kousky s obálkou) v rámci internetu host-to-host (i přes prostředníky, a.k.a. routery), síť je connection-less, paketová 102 | - Best-effort služba, není garance o doručení. 103 | 104 | Více v sekcích [IPv4](./6_pocitacove_site.md#funkce-ipv4) a [IPv6](./6_pocitacove_site.md#pokročilé-funkce-ipv6). 105 | 106 | ## transportní protokoly (TCP, UDP) 107 | 108 | ### UDP (User Datagram Protocol) 109 | 110 | - jednoduchý, poskytuje nespojovanou, best-effort službu (spolehlivost si musí případně řešit aplikace) 111 | - klíčová je jednoduchost => minimální režie, rychlost 112 | - používá se pro jednoduchou request-reply komunikaci (DNS), real-time přenosy (livestream), multicast 113 | 114 | Hlavička obsahuje 115 | - Zdrojový port 116 | - Cílový port 117 | - Celkovou délku 118 | - Checksum 119 | 120 | ### TCP (Transmission Control Protocol) 121 | - poskytuje spolehlivou spojovanou službu, uchovává pořadí 122 | - pracuje s byte streamy 123 | - komunikace musí být ustanovena 3way handshake (syn, syn&ack, ack) 124 | - komunikace je rozpoznatelná jen end-to-end, routery neřeší, že jde o spojení 125 | - nepodporuje multicast 126 | 127 | Hlavička obsahuje 128 | - zdrojový port 129 | - cílový port 130 | - sekvenční číslo (v rámci toku) 131 | - ack číslo - číslo dalšího očekávaného bajtu, potvrzuje přijetí dat 132 | - délka hlavičky 133 | - příznaky (ack, reset spojení, konec spojení...) 134 | - velikost okna (pro flow control) 135 | - checksum 136 | - options 137 | 138 | Tcp mění množství poslaných dat v průběhu komunikace, aby nebyl příjemce (Flow Control), nebo síť (Congestion Control) zahlcen/a, slouží k tomu **velikost okna**. 139 | - Flow Control znamená, že příjemce v rámci ACK zprávy pošle, kolik mu zbývá místa v jeho bufferu (např. 500 bytů), takže sender ví, že víc poslat nemůže. Když má příjemce plný buffer, tak pošle, že jeho window size je 0 a odesílatel čeká, dokud nepřijde nová ACK zpráva od příjemce o tom, že už má volné místo v bufferu. 140 | - Congestion Control funguje tak, že při startu se exponenciálně zvyšuje velikost okna, dokud nedosáhneme učité hranice. Od této hranice lineárně zvyšujeme velikost, dokud nedojde ke ztrátě paketu. V ten moment snížíme velikost na hraniční hodnotu a pokračujeme v lineárním zvyšování rychlosti. Jednotlivé varianty si tuto metodu přizpůsobují, e.g. Tahoe po ztrátě jde na minimální velikost okna (jako na úplném začátku), Reno praktikuje popsaný postup. 141 | - Výsledný strop pro velikost odeslaných dat je dán minimální hodnotou těchto dvou parametrů. 142 | 143 | ## Protokoly na síťových vrstvách 144 | - Aplikační - HTTP, SMTP, DNS, FTP... 145 | - Transportní - TCP UDP 146 | - Síťová IP - IPv4 (spolu s ARP, RARP, ICMP, IGMP), IPv6 (ICMPv6) 147 | - pro směrování Distance vector: RIP, IGRP, EIGRP, Link state: OSPF, IS-IS 148 | - Vrstva síťového rozhraní - ethernet, 802.11 (Wi-Fi) 149 | 150 | ## funkce IPv4 151 | 152 | Protokol umožňující komunikaci host-to-host. 153 | 154 | - 32 bitů, 0.0.0.0 - 255.255.255.255 155 | - typy adres 156 | - **unicast** - komunikace 1 na 1 157 | - **broadcast** - zpráva všem na LAN 158 | - **multicast** - zpráva těm, kteří se přihlásili k odběru dat na dané multicast adrese 159 | 160 | Hlavička obsahuje 161 | - verzi 162 | - délku hlavičky 163 | - type of service (pro zajištění quality of service) 164 | - celkovou délku datagramu 165 | - identifikaci, flags, offset (používá se při fragmentaci, rozdělení datagramu na vícero, pokud přenosová technologie nezvládá velikost) 166 | - time to live (dekrementován na každém hopu/routeru, při hodnotě 0 je paket zahozen, slouží k eliminaci zatoulaných paketů) 167 | - protokol - specifikace protokolu vyšší úrovně, ICMP, IGMP, TCP, UDP, OSPF... 168 | - checksum hlavičky (ne těla, protože by přepočítávání trvalo déle, děje se na každém hopu kvůli změně TTL) 169 | - adresa odesilatele i příjemce 170 | - options - slouží pro testování, debugging, volitelná část díky poli "délka hlavičky" 171 | 172 | IPv4 obecně 173 | - spolupracuje s protokoly 174 | - ICMP - poskytuje informace o stavu sítě (e.g. echo request/reply), poskytuje odesilateli inforace o chybě doručení (e.g. příjemce nedosažitelný, TTL šlo na nulu) 175 | - IGMP - správa skupin pro multicast, (od)registrace do skupin 176 | - ARP, RARP - překlad IP na MAC a obRáceně 177 | - umožňuje multicast 178 | 179 | 180 | Původně se IP adresy dělily pouze do tříd 181 | 182 | ![](img/20230530162603.png) 183 | 184 | kvůli nedostatku se začala používat i maska sítě (CIDR) 185 | 186 | 127.0.0.1 je loopback 187 | 188 | ## pokročilé funkce IPv6 189 | - řeší problém nedostatku IPv4 adres 128 bitovou délkou 190 | - `0000:0000:0000:0000:0000:0000:0000:0000` - `FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF` 191 | - možnost zkráceného zápisu: 192 | - vynecháním prefixových nul 193 | - `1050:0000:0000:0000:0005:0600:300c:326b` lze přepsat na 194 | - `1050:0:0:0:5:600:300c:326b` 195 | - dále vynecháním nejvýše jedné sekvence nul: 196 | - `1050::5:600:300c:326b` 197 | - oproti IPv4 198 | - IPSec je povinnou součástí 199 | - delší adresa => možnost více zařízení v síti 200 | - jednodušší hlavička (chybí checksum (úplně odstraněn), options, fragmentation) s možností extension headers 201 | - podpora označování toků a jejich priorit 202 | - podpora bezpečnosti, šifrování, autentizace, integrity dat 203 | - podpora mobility - každé zařízení je někde doma, kde má svého *Home Agenta*. Pokud je zařízení mimo domov, posílá informace o své cizí adrese Home Agentovi, který se stará o případné přeposílání zpráv, nebo spolupracuje pro ustanovení přímého tunelu 204 | - podpora autokonfigurace zařízení 205 | - má i **anycast** - jako multicast, ale stačí, aby se data doručily jen jednomu členu skupiny 206 | - odebrána fragmentace při doručování, toto si musí ohlídat odesílatel. Pokud je datagram moc velký, je zahozen a vygeneruje se ICMP zpráva obsahující zprávu o maximální velikosti na daném linku (procesu určení správné velikosti se říká **Path MTU Discovery** - pošli datagram, když se nevejde, fragmentuj na hodnotu dle ICMP zprávy, opakuj proces. MTU = maximum transmission unit) 207 | - odebrání checksumu (řeší se na nižší, nebo vyšší vrstvě) 208 | - broadcast nahrazen specifickými multicastovými skupinami (e.g. skupina routerů na LAN) 209 | 210 | Hlavička (40B) obsahuje 211 | - Verzi protokolu 212 | - prioritu (obsahuje i pole, které může indikovat, zda byla po cestě zaznamenáno zpoždění) 213 | - label toku (pakety jednoho toku musí být zpracovány stejným způsobem, volbu směrování lze kešovat) 214 | - délka dat 215 | - další hlavička - může být rozšiřující hlavička (auth, options...), nebo třeba TCP hlavička dat 216 | - hop limit 217 | - adresy 218 | 219 | Podpůrný ICMPv6 rozšiřuje funkcionalitu i o to co dělal IGMP a ARP. 220 | - původní ARP nahrazuje **Neighbour Discovery Protocol**, který řeší 221 | - autokonfiguraci IPv6 adresy (možnost i bez DHCP serveru) na základě síťového prefixu (info od routerů), MAC adresy/lokálně unikátního ID 222 | - detekci kolizí adres IPv6 (odešle zprávu na svou adresu, pokud někdo jiný odpoví, máme duplikát) 223 | - určení MAC adres uzlů na stejném linku, sledování změn 224 | - určení sousedů, kteří mohou přeposílat pakety dál 225 | - sledování dostupnosti sousedů 226 | - funguje díky komunikaci přes multicast skupiny 227 | 228 | (Pod)síť definována pomocí CIDR notace (všichni v síti sdílí stejný prefix) 229 | 230 | *Přechod z IPv4 na IPv6* 231 | - nutnost úpravy legacy systémů 232 | - složitější zpracovávání IPv6 adresy 233 | - ideální je dnes dělat aplikaci fungující s obojím, alternativně je potřeba použít enkapsulaci (tunelování) IPv6 do IPv4 paketů, nebo překládání (NAT) 234 | 235 | ## Peer-to-peer (P2P) sítě 236 | 237 | Systém je tvořen vícero identickými (a na stejné úrovni) moduly, peery, které vzájemně komunikují. Každý peer funguje jako klient (posílá požadavky) i server (odpovídá na požadavky) současně. U P2P není potřeba znát topologii celé sítě. 238 | 239 | Oproti Server-Client: 240 | - lepší škálovatelnost (ale u C-S lze poměrně solidně obstát s load balancingem)- s počtem klientů roste i výpočetní kapacita 241 | - decentralizace - fajn z pohledu dostupnosti (pád 1 peera neznamená pád celého systému) 242 | - může být problém z pohledu konzistence dat 243 | - větší proměnlivost topologie 244 | - sdílení výpočetní kapacity 245 | - sebeorganizace 246 | - C-S je jednodušší a zavedenější na vývoj, snadněji se spravuje 247 | - v C-S je server jasnou autoritou, která zajišťuje bezpečnost a autenticitu dat, u P2P je to složitější zajistit 248 | 249 | E.g. 250 | - distribuované výpočty Folding@Home 251 | - filesharing BitTorrent 252 | - Apache Cassandra (db) 253 | - blockchain (veřejný - kryptoměny, privátní - e.g. Hyperledger) 254 | 255 | Vrstvy: 256 | - Aplikace 257 | - Middleware 258 | - abstrakce nad overlay, poskytuje přístup ke službám/zdrojům peerů, kontroluje přístup ke službám/zdrojům, hledání a udržování zdrojů (skupin peerů) distribuovaných služeb 259 | - Base overlay 260 | - vrstva nad fyzickou sítí (obvykle TCP/UDP), kde se peery berou jako hopy (fyzicky vzdálení mohou být v p2p síti sousedi a naopak) 261 | - peer discovery, přeposílání zpráv, udržování (části) sítě 262 | 263 | Peer discovery 264 | - **Static/Manuální** - peer má předkonfigurovaný seznam informací o ostatních možných peerech (ip, port), na ty se zkouší připojovat. Nevhodné pro dynamické systémy, u větších systémů lze omezit seznam na pár dlouhodobě běžících stabilnějších peerů. 265 | - **Centralizovaný registr peerů** - udržuje seznam aktivních peerů, používá se pro discovery, následně probíhá komunikace napřímo. Registr je de fakto server, single point of failure. Registr provádí healthcheck (peer může znenadání spadnout, takže odhlašování při ukončení peera nestačí) 266 | 267 | Service discovery lze pomocí záplavy sítě dotazy (nestrukturované sítě, každý peer zodpovídá za svá data/služby, zpráva má TTL pro prevenci zahlcení, je možné použít DFS/BFS/IDS/heuristiky/náhodné procházky... na základě most promising), nebo je nějaký registr (strukturované sítě, regitr je centrální, a/nebo data jsou v distribuované tabulce, skip listu...), případně jako registr slouží vybraní peerové (hybridní sítě). 268 | 269 | Topologie overlay (jak jsou mezi sebou peerové vzájemně provázání) určuje celkovou výkonost p2p sítě. Snažíme se vyhnout lineárním formacím, splitům. 270 | - **Random mesh** - po discovery peerů se k několika z nich připojím (vybírám podle latence, díky tomu je větší šance výběru fyzicky blízkých peerů). 271 | - **Vrstvy** - peeři se organizují do vrstev dle poskytovaných služeb/připojení, na nejvyšší úrovni jsou ti nejspolehlivější s kapacitou přeposílání zpráv, na každé vrstvě je peer spojen s několika peery nižších vrstev a přeposílá zprávy na vyšší/nižší vrstvy. Struktura je tree-like, ale je třeba zajistit, aby výpadek jednoho nezpůsobil rozdělení sítě. Fajn třeba pro video streaming - peer může zprávu jdoucí dolů zduplikovat a šetřit tak bandwidth na vyšších vrstvách. 272 | - **Mřížka/Grid** - peeři jsou propojeni do mřížky (může být vícedimenzionální, i okrajoví mohou být vzájemně propojení). Problém může být přidávání/odebírání peerů, řádky/sloupce nemusí mít konzistentní počet členů. Koordináty peerů mohou být použity k adresování poskytovaných služeb 273 | 274 | 275 | ## ad-hoc/senzorové sítě 276 | 277 | Ideálně začít popisem [ad-hoc](./6_pocitacove_site.md#ad-hoc) a [senzorových](./6_pocitacove_site.md#senzorové-sítě) sítí. 278 | 279 | Rádiové sítě obecně 280 | - distribuované řízení ke sdílenému médiu 281 | - možná nutnost řešení problému odposlechů 282 | - možná velká chybovost, kolize... => používají se spojované protokoly, které mohou mít rezervační, nebo plánovací mechanismy pro zajištění QoS. 283 | - pro signalizaci přenosu (aby byla zajištěna prevence kolizí) je nutné použít separátní kanál, nebo tato signalizace musí proběhnout před samotným přenosem 284 | - absence interference u odesílatele neznamená nutně absenci interference u přijímajícího 285 | 286 | ### Ad-hoc 287 | 288 | - Sítě fungující bez předešlé existující infrastruktury, využívající síťových schopností jednotlivců => distribuované 289 | - Každý účastník funguje zároveň jako host 290 | - Na rozdíl od P2P sítí 291 | - je mnohem větší dynamicita topologie, mobilita účastníků 292 | - účastníci jsou sami zodpovědni za přístup k přenosovému médiu (často je to vzduch -> možná vysoká chybovost, interference) 293 | => nutnost specializovaných protokolů 294 | 295 | Příklady 296 | - komunikace mezi autonomními automobily 297 | - vytvoření komunikační infrastruktury při nouzových/záchranných situacích 298 | - za mini-ad-hoc síť by se daly považovat sledovací tagy, které využívají síťových schopností mobilních telefonů 299 | 300 | Směrování může být 301 | - adresové - každý účastník musí mít přiřazenou unikátní adresu, problém je najít ho v síti. Výhodou je podpora uni/multi/broadcastu 302 | - data-centrické - zprávy na sobě nemají cílovou adresu, ale identifikátor dat. Příjemci v síti avizují, o jaká data mají zájem -> ta jsou jim přeposílána, není nutnost řešit unikátní adresy 303 | 304 | Další dělení směrování 305 | - proaktivní (pravidelná výměna informací o stavu sítě, udržuje se info o topologii) vs reaktivní (nutnost flooding), záleží na kýžené rychlosti a vytížnosti sítě, energetických nárocích.. 306 | - směrování hop-by-hop vs znalost celé topologie 307 | - flat vs hierarchické (nadřízení mohou mít přidané zodpovědnosti, používají specializované algoritmy...) 308 | 309 | ### Senzorové sítě 310 | 311 | Koncová zařízení jsou obvykle zařízení obsahující 312 | - procesor a paměť 313 | - komunikační modul (rádio) 314 | - baterii (může být i s hw pro sběr energie, e.g. solární panel) 315 | - samotný senzor (světlo, pohyb...) 316 | 317 | Specifikem senzorových sítí je 318 | - důraz na energickou efektivitu, protože baterka může být malá, přísun energie omezený.. (toto mohou mít společné s ad-hoc sítěmi) 319 | - omezenou výpočetní/paměťovou kapacitu 320 | - omezenou šířku pásma 321 | - možnou nespolehlivost 322 | - nutnost řešit unikátní adresování (obvykle to v sobě tato zařízení nemají pořešené) 323 | - možný důraz na sebeorganizaci, multi-hop v rámci sítě 324 | - pro šetření energie se může používat dočasné uspávání zařízení v případě neaktivity v síti 325 | 326 | Příklady 327 | - sledování přírodních jevů, chování/přesunů (ohrožených) zvířat 328 | - detekce požárů, zemětřesení, vln 329 | - automatizace zemědělství, detekce sucha, škůdců... 330 | - řízení dopravy 331 | - automatizace řízení teploty v budovách 332 | - měření kvality vzduchu 333 | - zabezpečení objektů 334 | 335 | ## počítačové sítě a multimédia 336 | 337 | **Multimédia** data složená z různých typů médií (text, zvuk, video, obrázky...) integrovaných dohromady. E.g. videokonference (video + zvuk), televize/stream (video + zvuk + (text, titulky)). Některé média mohou být analogové, pro přenos je nutná konverze. Je kýžená komprese pro snížení objemu přenášených dat, ale komprese může znamenat overhead navíc, což nemusí být přijatelné u realtime přenosů. Dle aplikace nám může (ne)vadit chybovost. 338 | 339 | **Delay** - doba přenosu ze zdroje k cíli (člověk si všimne latence > 100-200 ms) 340 | - **Processing delay** - časový overhead u odesílatele/příjemce, záleží na rychlosti/vytíženosti komunikujícího systému 341 | - **Transmission delay** - doba, jakou trvá nacpat všechny bity do přenosového média (záleží na velikosti) 342 | - **Propagation delay** - doba přenosu přes samotné přenosové médium, záleží na technologii a vzdálenosti 343 | - **Routing/queuing delay** - záleží na vytíženosti sítě, rychlosti směrování 344 | **Jitter** - rozdílná doba přenosu mezi jednotlivými pakety 345 | 346 | Pro minimalizaci overheadu a zajištění maximální rychlosti (i za cenu chyb, výpadků...) se pro realtime aplikace používá UDP, příjemce může používat techniky jako odhadování chybějících dat, případně odesílatel může použít techniky pro detekci/korekci chyb pomocí redundance (nebo opětovaného zaslání). 347 | 348 | Je možné použít interleaving - e.g. u videa přeskládáme sousedící snímky tak, aby nesousedily. Pokud vypadne paket, tak bude ovlivněno sice více částí, ale každá jen trochu, namísto znatelného výpadku jedné části. Toto ale zvyšuje latenci. 349 | 350 | Pro realtime přenosy se používá multicast, namísto spousty unicastů (síť není zahlcená tolik). Pokud multicast síť nepodporuje, můžeme na ní nasadit reflektor - odesílatel posílá jeden datový tok, reflektor přijímá a replikuje příjemcům, každému unicastem. 351 | 352 | Média se mohou přenášet diskretizovaně (soubor, zpráva), nebo kontinuálně (stream). 353 | 354 | **Text** - e.g. HTTP, SMTP, FTP, vyžaduje relativně málo bandwidth, delay a nároky na chybovost závisí na aplikaci. Komprese e.g. pomocí huffman, nebo shannon-fano kódování (více v [otázka 5 - databáze](./5_databaze.md#kódování-a-komprese-dat)), na webu se používá gzip (obsahuje huffmana), drobné chyby dělají problémy 355 | **Audio** - v základu analog, digitalizace pomocí vzorkování (hodnota v čase) signálu a kvantitatizace (mapování e.g. na celá čísla). Požadavky na šířku pásma záleží na požadované kvalitě a případné komprimaci, jsme ochotni tolerovat drobné chyby 356 | **Grafika** - obvykle nejsou požadavky na rychlost (pokud není tragická) 357 | **Video** - obvykle náročné na šířku pásma, jinak se specifiky podobá audiu 358 | 359 | 360 | ## Notes 361 | 362 | **Protokol** je sada syntaktických (jak mají jednotlivé zprávy vypadat) a sémantických (jaký je význam jednotlivých zpráv) pravidel pro komunikaci nebo výměnu dat mezi systémy/zařízeními/komunikačními partnery 363 | 364 | **CIDR** - kromě IP adresy uchováváme i masku sítě (e.g. 147.209.5.0/24 říká, že relevantních je jen prvních 24 bitů). Umožňuje subneting a efektivnější směrování - pokud máme v tabulkce adresy se stejným prefixem a stejnou cestou, můžeme říct, že naší cestou mají chodit pakety pro celý prefix 365 | 366 | **Piggybacking** - Pokud chceme odesilateli poslat nějaká data a zároveň potvrdit příjem dat, můžeme tyto informace spojit do jednoho paketu 367 | 368 | **NAT** Překlad adres na rozhraní sítě. E.g. pro naši síť máme 1 veřejnou IP adresu. Aby se zajistilo správné směrování všem v síti, musí se na rozhraní překládat veřejná adresa na interní adresu. 369 | 370 | **SSL, TLS** - Kryptografické protokoly (SSL nahrazen TLS) používané mezi transportní a aplikační vrstvou, zajišťují autenticitu a šifrování dat komunikujících stran. Nejprve se účastníci dohodnou na podporovaných algoritmech, pak proběhne výměna klíčů (pro symetrické šifrování) založená na asymetrickém šifrování (certifikát serveru, může požadovat i certifikát klienta). Pak probíhá komunikace pomocí symetrického šifrování. 371 | 372 | Pro zefetkivnění směrování je možné použít **Multiprotocol Label Switching** - pro předpokládané/známé toky definujeme cesty, každému toku dáme label a směrujeme jen podle labelů (rychlejší, je možné nastavit i více cest, třeba jako backup, nebo pro distribuci pro load balancing). 373 | 374 | **Flow control** se řeší pro příjemce, **congestion control** se řeší pro síť 375 | 376 | **Autenticita** - data jsou od správného odesilatele 377 | 378 | **Integrita** - data nebyla cestou změněna 379 | 380 | **Šifrování** - data nejsou čitelná/srozumitelná třetím stranám 381 | -------------------------------------------------------------------------------- /dev_1_analyza_a_navrh.md: -------------------------------------------------------------------------------- 1 | # Analýza a návrh systémů 2 | 3 | > Objektové metody návrhu informačních systémů. Specifikace a řízení požadavků. Softwarové architektury, komponentové systémy. Návrhové a architektonické vzory. Rozhraní komponent, kontrakty na úrovni rozhraní, OCL. Modely softwarových systémů, jazyk UML. Příklady z praxe pro vše výše uvedené. ([PA103](https://is.muni.cz/auth/el/fi/podzim2021/PA103/um/), PV167, [PV258](https://is.muni.cz/auth/el/fi/jaro2021/PV258/um/)) 4 | 5 | ## Objektové metody návrhu informačních systémů. 6 | 7 | Přístupy a postupy k návrhu IS založených na objektově orientovaném paradigmatu, kde jsou objekty spojením dat a metod nad těmito daty. 8 | 9 | Při modelování systému je dobré definovat si jednotný jazyk, který reflektuje skutečnou terminologii pro danou doménu problému. Podle toho volíme jména funkcí/tříd, aby bylo pokaždé všem (od doménových expertů po vývojáře) jasné, o čem se mluví. Podstatná jména používaná v jednotném jazyce obvykle v kódu reflektují třídy/rozhraní, slovesa zase metody/funkce. 10 | 11 | Objektové paradigma si dobře rozumí s principy abstrakce, což lze aplikovat nejen na úroveň objektů, ale i komponentů - základních stavebních jednotek, ze kterých se skládá architektura systému. 12 | 13 | Mezi metody se řadí: 14 | - modelování domény pomocí [UML](./dev_1_analyza_a_navrh.md#modely-softwarových-systémů-jazyk-uml), v různých částích vývoje se zabýváme různými úrovněmi detailů 15 | - dekompozice systému do menších, koherentních částí 16 | - aplikace návrhových a architektonických vzorů, které popisují řešení na dobře známé a často se opakující problémy v (nejen) objektovém světě. 17 | 18 | ## Specifikace a řízení požadavků. 19 | 20 | Požadavky na systém se dělí (obvykle je mezi kategoriemi tenká hranice a závisí i na formulaci) na: 21 | - **Funkční (functional) požadavky** - jaké funkce zákazník od systému očekává, jedná se o business logiku, uživatelské požadavky, řeší se programově, v implementaci 22 | - **Nefunkční (non-functional/quality) požadavky** - jaké technické nároky jsou na systém, použité technologie, OS, garance dostupnosti (availability), response time, internacionalizace a lokalizace, řeší se návrhem, architekturou i kódem 23 | 24 | Součástí řízení požadavku je 25 | - porozumnění doméně problému 26 | - sběr požadavků od stakeholderů - klíčem je ptát se PROČ, ne CO a JAK 27 | - analýza a jednání (hej, toto není možné/hej, nestačilo by vám to udělat takto?...) 28 | - specifikace požadavků - úprava do jednoznačné/formální podoby (use case). Je jasné, v jakém momentě můžeme považovat za splněný. 29 | - validace požadavků - ověření, že formalizované požadavky odpovídají skutečným potřebám 30 | - prioritizace požadavků - umožňuje soustředit se na kritické části (dle potřeb zákazníka) a blbosti případně vynechat, pokud nebude čas/rozpočet. 31 | 32 | Dobrý/dobře specifikovaný požadavek 33 | - reflektuje skutečné potřeby zákazníka a je v něm obsaženo PROČ (abychom mohli vybrat nejvhodnější řešení, ale může obsahovat návrhy) 34 | - má jasné kritérium splnění, je měřitelný a testovatelný 35 | - má prioritu 36 | - je úplný 37 | 38 | Obecně platí, že čím později se požadavek změní, tím nákladnější bude jeho implementace. 39 | 40 | Požadavky se modelují pomocí **use case diagramu**, uchovávají se v **use case dokumentu** (forma: id, jméno, actor(s), popis, trigger, pre/post conditions, příklad typického flow, priorita, výjimky, častost používání...). Požadavky jsou také formalizovány v jednoduché formě pomocí **user stories** - krátké, výstižné popisy (As `role` I want to `akce` So I can `zdůvodnění`), srozumitelní zákazníkovi (+ obsahují akceptační kritéria, prioritu, story pointy...). 41 | 42 | Pro **určení priority požadavku** lze použít například: 43 | - klasické ohodnocení 1-10 44 | - binární strom - požadavky jsou uchovávány v uzlech. Vkládaný požadavek srovnáváme s uzly od kořene. Pokud je vkládaný požadavek prioritnější, jdeme doprava. Jinak jdeme doleva. Vložený požadavek bude listem stromu. 45 | - MoSCoW - požadavky dělíme na Must (kritické), Should (důležité), Could (bylo by fajn mít) a Won't (aktuálně to nemáme v plánu) 46 | 47 | Non-functional requirements platí vždy, je třeba je brát v potaz i s nově příchozími functional požadavky => máme pro ně vyhrazené místo (e.g. wiki), kde jsou důkladně popsány. Můžeme na konkrétní NFR poukázat v user stories (e.g. u FR `jako uživatel chci mít přístup k aktuálním datům senzoru` linkneme NFR `systém poskytne odezvu do vteřiny` a `data ze senzorů se do systému dostanou nejpozději minutu po naměření`). 48 | 49 | 50 | ## Softwarové architektury, komponentové systémy. 51 | 52 | Sw architektura určuje, jakým způsobem je systém strukturován, jakým způsobem je dělen na komponenty/moduly a jak mezi sebou jednotlivé komponenty/moduly interagují a jak jsou jednotlivé části systému nasazeny na hw. 53 | 54 | SW architektury (vyšší úroveň abstrakce) a architektonické vzory (nižší úroveň abstrakce) jsou obecná řešení architektur systému. Uvádím jen seznam, podrobně jsou popsány v [části otázky 1](./1_programovani_a_softwarovy_vyvoj.md#základní-koncepty-softwarových-architektur-z-pohledu-implementace-vícevrstvá-architektura-moderních-informačních-systémů-architektura-model-view-controller) 55 | - **MVC/MVP/MVVM pattern** 56 | - **Klient-Server** 57 | - **Peer-to-Peer** 58 | - **Layered architecture** - vrstvená architektura používá architektonický vzor Repository 59 | - **Microkernel** 60 | - **Pipes and filters** 61 | - **Blackboard** - tabule je sdílená, jsou na ní data. Výpočetní agenti k tabuli přistupují a zpracovávají data dle svých interních strategií. Klient následně vybere agenta, který přišel s nejlepším řešením, na základě čehož se aktualizují data na tabuli. Nedeterministický výpočet. e.g. použití různých algoritmů u kterých nevíme, jaký je nejlepší. 62 | - **SOA** 63 | - **Microservices** 64 | 65 | Komponenty jsou spustitelné softwarové jednotky, která mají definované komunikační rozhraní, do vnitřního fungování nevidíme/nezajímá nás. Komponent by měl poskytovat logicky související funkcionalitu, funguje jako vrstva abstrakce. Komponenty mohou být vyvíjeny nezávisle na jiných komponentech, jsou nahraditelné (stačí splnit rozhraní a jeho kontrakt), znovupoužitelné. Komponenty mohou mít vnitřní stav, ten však může dělat problém u škálování (paralelizací komponentů), mohou být asynchronní, mohou se interně skládat z dalších komponentů... 66 | 67 | Pokud systém vystavuje rozhraní používaná i někým jiným (klient), je fajn nějakým způsobem verzovat rozhraní. Díky tomu se předejde problémům při přidávání změn, nějakou dobu totiž můžeme podporovat vícero rozhraní, než se klient aktualizuje na novou verzi. 68 | 69 | ## Návrhové a architektonické vzory. 70 | 71 | Návrhový vzor je obecné řešení k často se opakujícímu problému řešenému při návrhu sw, není potřeba kompletně vymýšlet vlastní řešení. Slouží nejen jako obecný návod pro implementaci, ale umožňují snadnější komunikaci v rámci týmu (e.g. tady použijeme Strategy pattern). Vzory je třeba používat s rozvahou, občas můžou být zbytečně obecné. 72 | 73 | *Architektonické vzory jsou popsány v [předchozí podotázce](./dev_1_analyza_a_navrh.md#softwarové-architektury-komponentové-systémy)*. 74 | 75 | [Pro pochopení a ukázky kódu](https://refactoring.guru/design-patterns) 76 | 77 | ### Creational patterns 78 | 79 | Řeší tvobu a inicializaci objektů, poskytují jednoduché rozhraní skrývající složitou inicializaci. 80 | 81 | #### Singleton 82 | 83 | Zajišťuje, že daný objekt existuje v systému jen jednou (globální stav). V OO jazycích se řeší pomocí třídy s private constructorem a se statickou metodou `instance()` poskytující přístup k objektu drženému ve statickém atributu. *Metoda `instance() se obvykle stará i o inicializaci statického atributu* 84 | 85 | Singleton je mnohdy považován za antivzor, protože vytváří globální stav (namísto předávání stavu parametry) - blbě se to testuje, může být nutné zamykání globálního stavu pro thread safety, narušuje se single responsibility principle (singleton třída ovládá svou tvorbu). 86 | 87 | E.g. DB pool 88 | 89 | ![](img/20230603121311.png) 90 | 91 | #### Factory method 92 | 93 | Stará se o tvorbu konkrétních instancí objektů dle instance továrny (i.e., máme interfaces VehicleFactory a Vehicle. CarFactory bude dělat Car, zatímco stejné volání metody u PlaneFactory vytvoří Plane). Používá se pokud potřebujeme flexibilní a rozšiřitelný způsob vytváření objektů, nebo chceme oddělit logiku tvorby objektu od zbytku. Nevýhodou je nutnost tvorby nové Factory třídy a rozhraní. 94 | 95 | ![](img/20230604152821.png) 96 | 97 | #### Abstract factory 98 | 99 | Podobná factory method, ale je zodpovědná za více produktů. Instance této factory zajišťuje tvorbu vzájemně kompatibilních produktů. 100 | 101 | ![](img/20230605121553.png) 102 | 103 | #### Prototype 104 | 105 | Doslova trait `Clone`, vytvoří identickou kopii nějakého již existujícího objektu. Hodí se, pokud inicializace objektu je náročná, nebo neznáme konkrétní instanci (pracujeme s abstrakcí přes interface). 106 | 107 | ![](img/20230604183448.png) 108 | 109 | #### Builder pattern 110 | 111 | Ke konfiguraci objektu při inicializaci používáme (deklarativním způsobem) metody příslušného `Builder` objektu, každá se stará o jeden aspekt. 112 | 113 | E.g. Inicializace http požadavku 114 | 115 | ```rust 116 | let request = HttpRequest::get("www.mysite.com/content") 117 | .header("Authorization", "Bearer 8sa96d41a5s3fbwn") 118 | .queryParam("offset", 42) 119 | .build(); 120 | ``` 121 | 122 | ![](img/20230604183525.png) 123 | 124 | 125 | ### Structural patterns 126 | 127 | Řeší kompozici objektů do hierarchií, oddělení rozhraní a implementace. 128 | 129 | #### Composite 130 | 131 | Umožňuje tvorbu stromových struktur a poskytuje jednotné rozhraní k operaci na podstromu definovaném svým kořenem.`Component` je buď list `Leaf`, nebo uzel `Composite` obsahující potenciálně další `Component`y. 132 | 133 | E.g. stavební prvky grafických rozhraní 134 | 135 | ![](img/20230603143753.png) 136 | 137 | #### Adapter 138 | 139 | A.k.a. Wrapper - zapouzdříme/poskytneme rozhraní nekompatibilní jednotce tak, aby se dala použít v našem systému. 140 | 141 | E.g. integrace knihovny, případně můžeme adaptér použít k převodu mezi formáty (XML - JSON) 142 | 143 | Adaptér lze implementovat ve všech populárních jazycích jako wrapper, je možná i implementace class adaptéru v jazycích podporujících mnohonásobnou dědičnost. 144 | 145 | ![](img/20230603161229.png) 146 | 147 | #### Bridge 148 | 149 | Používá se k rozbití tightly coupled jednotek (nebo skupiny jednotek) pomocí abstrakcí (ty mohou mít vícero implementací, ale často nám bridge pomůže jen díky vytvoření abstrakce). 150 | 151 | E.g. Fullstack aplikaci využívající templating rozbijeme na frontend a backend api. 152 | 153 | ![](img/20230604142514.png) 154 | 155 | #### Decorator 156 | 157 | Umožňuje rozšířit třídu, přidat k ní různé metody/atributy na základě použitého dekorátoru, dynamicky je přidávat/odebírat. Obdobně jako Adapter může obalit původní komponent, ale nemění rozhraní komponentu. 158 | 159 | E.g. BufReader pro bufferované čtení (ze souboru), BufReader obaluje Reader a přidává buffer. 160 | 161 | ![](img/20230604142455.png) 162 | 163 | #### Proxy 164 | 165 | Prostředník mezi objektem a volajícím, transparentně předává zprávu (a může provádět další operace, hlídat přístup k objektu, provést alokaci objektu on-demand...). 166 | 167 | ![](img/20230605125209.png) 168 | 169 | #### Facade 170 | 171 | Poskytuje jednotné (a jednoduché) rozhraní složitějšímu subsystému. 172 | 173 | ![](img/20230605125311.png) 174 | 175 | #### Flyweight 176 | 177 | Sdílený objekt použitý na vícero místech - sdílený stav je uchováván v objektu, kontextuální stav se dodá skrz parametry volané metody. Slouží k úspoře paměti a/nebo výpočtu (pokud je inicializace drahá). 178 | 179 | E.g. DB pool 180 | 181 | ![](img/20230605130130.png) 182 | 183 | ### Behavioral patterns 184 | 185 | Řeší chování objektů a dynamické interakce mezi objekty. 186 | 187 | #### Iterator 188 | 189 | Poskytuje jednotné rozhraní k průchodu prvky kolekcí. Je to samostatný objekt (specifický pro danou strukturu), má metody jako `current()` a `next()` umožňující přístup k prvku, nebo posunutí interního ukazatele iterátoru na další prvek. 190 | 191 | E.g. implementace `for-in/foreach`. 192 | 193 | ![](img/20230603144800.png) 194 | 195 | #### Strategy 196 | 197 | Poskytuje rozhraní k výpočtu/operaci, které může klient použít bez znalosti konkrétní implementace a jejích detailů. Díky tomu je možné konkrétní implementace pro výpočet snadno měnit, nebo jednotně používat funkcionalitu objektů s rozdílnými implementacemi. Klient přistupuje přes `Context`, který se stará o případnou volbu strategie. Konkrétní strategie lze měnit za běhu. *?Iterátor by se dal považovat za formu strategy?* 198 | 199 | E.g. libovolné použití přístupu přes rozhraní, třeba výpočet trasy (pro auto, pro cyklistu, pro chodce..) 200 | 201 | ![](img/20230603153352.png) 202 | 203 | #### State 204 | 205 | Obdobný jako Strategy, výběr implementace děláme na základě aktuálního stavu, který je možné měnit za běhu. O konkrétní stav (a výběr implementace) a jeho přeměny se stará `Context`, díky čemu izolujeme a můžeme jednoduše kontrolovat přechodu stavu v systému. 206 | 207 | Na rozdíl od `Strategy` 208 | - daná implementace je vybrána na základě vnitřního stavu 209 | - řešíme přechody stavu, stavy se můžou nahradit jiným stavem (=> stavy mohou mít referenci na kontext) 210 | - neřešíme jeden specifický task, ale poskytujeme implementaci pro většinu věcí co `Context` nabízí 211 | 212 | E.g. Vypínač má dva stavy (concrete state), Vypnutý Vypínač a ZapnutýVypínač. Interface Vypínač má metodu přepni(), čímž se změní stav (VypnutýVypínač na ZapnutýVypínač a opačně) 213 | 214 | ![](img/20230603154910.png) 215 | 216 | #### Memento 217 | 218 | Uchovává předchozí stavy objektu, díky čemuž je možné přenést objekt do dřívějšího stavu. Používá se pro případy, kdy přímý přístup do atributů třídy není možný (private atributy). 219 | 220 | E.g. použití při implementaci UNDO. 221 | 222 | ![](img/20230605132549.png) 223 | 224 | #### Observer 225 | 226 | Umožňuje tvorbu mechanismu pro notifikace. Observery se registrují ke sledování Subjektu (ukládáme si reference observerů do vektoru). V momentě, kdy se subjekt změní (a měly by být observery notifikovány), stačí zavolat metodu notify, která projde observery a každého notifikuje (obvykle zavoláním metody). 227 | 228 | Používá se pro nahrazení pollingu (opakovaně se ptám "už se událost stala?"). 229 | 230 | ![](img/20230605162806.png) 231 | 232 | #### Visitor 233 | 234 | Poskytuje jednotné rozhraní pro spuštění nějaké shodné akce nad objekty. Každý objekt má implementaci odlišnou, ale signatura pro všechny objekty je shodná (e.g. serializace různých struktur, bere Self, vrací String). Namísto abychom na základě typu struktury volali příslušnou metodu (`if let Vehicle::Car(_) = my_data { return serialize_car(my_data); }`), implementujeme metodu poskytnutou rozhraním (jen `serialize(&self)`). V diagramu je to metoda `accept(v: Visitor)`. 235 | 236 | E.g. serde 237 | 238 | ![](img/20230605165644.png) 239 | 240 | ## Rozhraní komponent, kontrakty na úrovni rozhraní, OCL 241 | 242 | Aby mohl komponent komunikovat se svým okolím (být volán a případně vracet data), potřebuje nějaké veřejné rozhraní, kterému se říká **signatura**. Skládá se z poskytovaných operací (funkcí/metod) a jejich vstupních a výstupních parametrů. 243 | 244 | U rozhraní nás zajímají i další omezení, které mohou upravovat (správné) používání rozhraní (*e.g. uživatel se může registrovat jen jednou*). Signatuře a omezení se souhrnně říká **kontrakt**. Kontrakt popisuje poskytnutou funkcionalitu za předpokladu, že dodržíme předem stanovené podmínky. 245 | 246 | Součástí kontraktu (v kontextu struktur/objektů) můžou být: 247 | - **preconditions** - co musí platit před vyvoláním dané metody, aby metoda proběhla správně (e.g. máme dost peněz na účtu) 248 | - **postconditions** - co musí platit po skončení dané metody, i.e., co metoda poskytuje (e.g. proběhne platba, z účtu se nám odečte příslušná platba) 249 | - **invariants** - co vždy musí platit, váže se obvykle k objektům, nejen metodám (e.g. na debetním účtu není možné jít do mínusu) 250 | 251 | **OCL (Object Constraint Language)** je deklarativní jazyk, který umožňuje popis kontraktů a jejich constraintů (omezení domén hodnot), včetně jejich zavedení do UML, a může být použit i pro jejich vynucování (e.g. generování kódu na základě kontraktu popsaného v komentáři/anotacích (v Javě `@`)). 252 | 253 | Při definici kontraktů objektů s dědičností nesmíme porušit Liskov substitution principle, dědic může invarianty a postconditions pouze utahovat, ne je rozvolňovat (co platilo pro rodiče, musí platit i pro potomka). Naopak je to u preconditions, kde může dědic podporovat více vstupů než předek. 254 | 255 | Příklady: 256 | 257 | Auto (třída Car) nesmí překročit rychlost 240. 258 | `context Car inv: speed < 240` 259 | ^ speed a self.speed (kde self je Car) jsou identické 260 | 261 | Před odebráním prvku musí zásobník něco obsahovat, vrací to co bylo na vrchu zásobníku 262 | ``` 263 | context Stack::pop() 264 | pre neniPrazdny: self.len() > 0 265 | post vraciVrsekZasobniku: result = self@pre.top() 266 | ``` 267 | 268 | Po vložení prvku se zvětší zásobník 269 | ``` 270 | context Stact::push(element) 271 | post: self.len() = self@pre.len() + 1 272 | ``` 273 | 274 | V OCL lze používat funkcionální přístup ke kolekcím (select, forAll...), řešit existenci (exists), provádět množinové operace (union, intersection...), používat booleovské operátory (or, and, implies...) a spoustu dalšího (proměnné, cykly...). 275 | 276 | ## Modely softwarových systémů, jazyk UML. 277 | 278 | Modely sw systémů popisují systém vždy z nějakého zjednodušeného pohledu (model je už z definice abstrakce). Různé modely se zabývají různými aspekty/fázemi vývoje systému. Důležité však je, aby byly modely systému vzájemně konzistentní. Obecně lze rozlišovat na modely popisující strukturu a modely popisující chování. 279 | 280 | **UML** je modelovací jazyk umožňující jednotný způsob vizualizace návrhu systému. Pro snadné verzování je fajn PlantUML (píšeme UML jako deklarativní kód, ze kterého generujeme příslušné diagramy). 281 | 282 | Příklad interface 283 | 284 | ![](img/20230605172409.png) 285 | 286 | ### Context diagram 287 | 288 | Popisuje kontext a prostředí, v jakém systém má fungovat. Jsou zde znázorněny interakce s externími systémy a skupinami uživatelů. 289 | 290 | ![](img/20230607124347.png) 291 | 292 | Neřešíme části, se kterými přímo neinteragujeme. Ty jsou vidět v [Ecosystem map](./dev_1_analyza_a_navrh.md#ecosystem-map). 293 | 294 | ### Use case diagram 295 | 296 | Zahrnuje všechny (uživatelé i jiné systémy), kteří budou systém používat ve formě actorů. U každého actora vidíme dostupné akce (use case) a případně vazby mezi akcemi (<--extend, include-->, spuštění další akce). 297 | 298 | | ![](img/20230607130528.png) | ![](img/20230607130605.png) | 299 | |---|---| 300 | 301 | ### Conceptual class diagram 302 | 303 | Diagram tříd, ale neřešíme datové typy ani metody. Zajímají nás klíčové entity (struktury/třídy), jejich data plynoucí z požadavků, a vazby mezi entitami (kontext). Pomáhá ujasňovat terminologii. 304 | 305 | ### Class diagram 306 | 307 | Statická reprezentace systému ve formě tříd, zobrazuje jejich metody, atributy a vzájemnou provázanost. Vztahy mají kardinalitu 308 | 309 | **Asociace** - klasická šipka (nebo čára pro oboustranný vztah), popisuje vztah daných tříd 310 | **Agregace** - bílý kosočtverec, popisuje, že třída obsahuje jinou třídu (u ní je kosočtverec) 311 | **Kompozice** - černý kosočtverec, popisuje, že třída (s kosočtvercem) je nedílnou součástí jiné třídy 312 | 313 | ![](img/20230608120634.png) 314 | 315 | ![](img/20230608120112.png) 316 | 317 | ### Object diagram 318 | 319 | Zachycuje systém za běhu v určitém čase, zobrazuje konkrétní objekty a jejich vazby. 320 | 321 | ![](img/20230608121047.png) 322 | 323 | ### Activity diagram 324 | 325 | Popisuje workflow systému/komponentu (dle úrovně abstrakce), jednoduchý na pochopení i pro zákazníka. 326 | 327 | ![](img/20230609000854.png) 328 | 329 | ### Sequence diagram 330 | 331 | Popisuje interakce v čase mezi jednotkami (třídami/komponenty/actory) systému 332 | 333 | ![](img/20230609001314.png) 334 | 335 | ### Deployment diagram 336 | 337 | Popisuje jednotlivé komponenty systému a jejich komunikační toky, včetně použitých technologií. 338 | 339 | ![](img/20230609001416.png) 340 | 341 | ### Component diagram 342 | 343 | Popisuje komponenty a jejich kompozici v sýstému. 344 | 345 | Třídní/lollipop notace 346 | 347 | ![](img/20230606160621.png) 348 | 349 | Komunikační rozhraní koponentů se nazývají porty, přímé spoje connectors. 350 | 351 | ![](img/20230606164944.png) 352 | 353 | ## Notes 354 | 355 | **Verifikace vs validace** - validace ověřuje, že náš model odpovídá požadavkům, verifikace ověřuje, že naše implementace odpovídá našemu modelu, že je implementace kvalitní. E.g. u mostu by se validovalo, že je postavený v místě, kde je potřeba. Verifikovalo by se, že je postavený správně. 356 | 357 | **Motivace objektových metod/návrhových vzorů** 358 | - Systémy bývají složité, špatně se udržují a je náročné měřit/zajistit kvalitu, často se mění nároky 359 | => pomůže dekompozice systému do menších koherentních částí, které se lépe udržují/mění, snadněji se měří kvalita 360 | 361 | Dekompozice podle [SOLID](./2_kvalita_kodu.md#solid-principy) 362 | - single responsibility - každý modul/třída/funkce by se měly soustředit pouze na jednu část funkcionality (a tu zapouzdřovat) 363 | - open/closed - každý modul/třída/(funkce) by měly být rozšiřitelné i.e. přidání změn způsobí minimální modifikaci kódu, většinou rozšiřujeme pomocí nových tříd/metod 364 | - liskov substitution - každý (dědičně) nadřazený objekt by měl být nahraditelný podřazeným objektem, aniž by byl narušen původní kontrakt. E.g. nemůžeme vyhodit výjimku, když to nadřazený nikdy nedělal. Nemužeme brát u stejné metody konkrétnější argument, než jaký bere nadřazený objekt (je v pohodě brát abstraktnější). Nemůžeme vracet abstraktnější typ, než jaký vrací nadřazený. Je v pohodě přidávat funkcionalitu ve formě dalších metod. 365 | - interface segregation - rozbíjíme velká rozhraní na menší, logicky související jednotky. Jen to, co klient opravdu může potřebovat. 366 | - dependency inversion - závisíme na abstrakcích (rozhraní), ne na konkrétních implementacích 367 | 368 | **Problém s cyklickou vazbou objektů** - e.g. v metodě toString() je potřeba vhodně řešit, abychom se necyklili. Proto může být vhodnější definovat si pro takové případy speciální objekty s jasnou hierarchií a bez cyklů 369 | 370 | **Interface Definition Language** - popisuje rozhraní formou, která je nezávislá na použitém programovacím jazyce (e.g. OpenAPI Specification pro REST, protocol buffer pr gRPC, Web Service Definition Language pro SOAP, CORBA IDL). Obvykle je možné pomocí IDL schématu vygenerovat v daném programovacím jazyce kód/struktury, který poskytovatel implementuje a uživatel používá. Více v [otázce 7](./7_distribuovane_systemy.md). 371 | 372 | **Event list** - seznam všech událostí, které mohou v systému nastat 373 | 374 | ### Ecosystem map 375 | 376 | Znázorňuje celý kontext (včetně částí, se kterými přímo nekomunikujeme), ve kterém náš systém funguje. 377 | 378 | ![](img/20230607124544.png) 379 | 380 | ### Analytické vzory 381 | Návrhové vzory nabízí řešení na často řešené problémy v návrzích systému. Tato řešení jsou místy až příliš sofistikovaná, takže se doporučuje složitější návrhové vzory používat z rozvahou, abychom problém *neoverengineeringovali*. 382 | 383 | Accountability vzory *(přijdou mi ve slajdech popsány složitější, než jsou, proto popisuju koncepty/zapamatovatelné aspekty, zbytek si člověk dokáže odvodit. Odkazy vedou na příslušnou část s diagramem.)* 384 | - [Party](./dev_1_analyza_a_navrh.md#party) - společný název (abstrakce) pro osobu či firmu, obvykle má kontaktní údaje (adresu, telefon, email...) 385 | - [Organization Hierarchies](./dev_1_analyza_a_navrh.md#organization-hierarchies) - řešíme problém reprezentace organizace skládající se z často měnících se hierarchií organizačních jednotek (e.g. Korporace, Region, Pobočka, Oddělení... typy jednotek mohou být také předmětem změn). Řešením je stavební blok `Organizace`, která má 0..1 rodiče `Organizace` a 0..n potomků `Organizace` (rekurzivní vazba). Jednotlivé typy oddělení pak mohou dědit od `Organizace`. 386 | - [Organization Structure](./dev_1_analyza_a_navrh.md#organization-structure) - To samé co organization hierarchies, ale přidáváme k tomu `TimePeriod` (pro verzování v čase), `Typ Organizační Struktury`, který může mít `Pravidla` zajišťující, že třeba oddělení nebude nadřízené divizi. 387 | - [Accountability](./dev_1_analyza_a_navrh.md#accountability) - Organization Structure, ale Organizaci nahradíme Party (a vztahu říkáme accountability). Je tam opět `TimePeriod`, ale `Typ Organizační Struktury` se jmenuje `Accountability Type`. `Pravidla` pro vazby zahazujeme 388 | - [Accountability Knowledge Level](./dev_1_analyza_a_navrh.md#accountability-knowledge-level) - Accountability, ale `Pravidla` pro vazby mezi jednotlivými `Party`s zase přidáme. `Pravidla` jsou definována pro jednotlivé `Accountability Type`s, každé definuje povolenou kombinaci `Party Type` potomka a rodiče v hierarchii. Úrovni, kde popisujeme pravidla (a kde tím pádem jsou i `Accountability Type`s a `Party Type`s) říkáme knowledge level, existuje jen pro zajištění správné kompozice (ale nemá moc význam pro day-to-day operace). 389 | 390 | Příklad pro aplikaci accountability je ve [slajdech (str 35+)](https://is.muni.cz/auth/el/fi/podzim2021/PA103/um/02-03-Analysis-patterns.pdf#page=35). 391 | 392 | Observations & measurements 393 | - [Quantity](./dev_1_analyza_a_navrh.md#quantity) - kvantita má hodnotu a jednotku (v Rustu bychom použili Newtype pattern konkrétní jednotky a pomocí traitů implementovali funkcionalitu) 394 | - [Conversion Ratio](./dev_1_analyza_a_navrh.md#conversion-ratio) - převedení jedné jednotky na jinou, samo o sobě funguje jen pro lineární vztahy 395 | - [Compound Units](./dev_1_analyza_a_navrh.md#compound-units) - Jednotka může být buď `Atomic Unit` (e.g. kilometry), nebo `Compound Unit`, která má aspoň jeden `Unit Reference` obsahující mocninu (e.g. kilometry za hodinu). 396 | - [Measurement](./dev_1_analyza_a_navrh.md#measurement) - Reprezentuje výsledek měření. Každé měření bylo někým vykonáno (`Person`), zkoumalo nějaký měřený fenomén (`Phenomenon Type`) a zjistilo nějakou hodnotu, včetně jednotek (`Quantity`) 397 | - [Observation](./dev_1_analyza_a_navrh.md#observation) - výše popsaný `Measurement` je typ `Observation`, stejně jako `Category Observation` umožňující zaznamenávat nekvantitativní měření s nějakou kategorickou hodnotou (e.g. počet lidí s danou krevní skupinou), kde nás zajímá konkrétní `Phenomenon` (e.g. A+), který je součástí `Phenomenon Type`. 398 | - je možné přidat i způsob měření `Protocol`, či sledovat přítomnost/nepřítomnost kategorického jevu, který může mít závislosti na (pod)jevech modelovaných pomocí `Observation Concept` (e.g. diabetik typu 2 je obecně diabetik) 399 | 400 | ### Diagramy analytických vzorů 401 | 402 | #### Party 403 | ![](img/20230602212700.png) 404 | 405 | #### Organization Hierarchies 406 | ![](img/20230602212810.png) 407 | 408 | #### Organization Structure 409 | 410 | ![](img/20230602221810.png) 411 | 412 | #### Accountability 413 | ![](img/20230602223147.png) 414 | 415 | #### Accountability Knowledge Level 416 | ![](img/20230602224136.png) 417 | 418 | #### Quantity 419 | ![](img/20230603105247.png) 420 | 421 | #### Conversion Ratio 422 | ![](img/20230603105928.png) 423 | 424 | #### Compound Units 425 | ![](img/20230603110857.png) 426 | 427 | #### Measurement 428 | ![](img/20230603111248.png) 429 | 430 | #### Observation 431 | ![](img/20230603112121.png) 432 | 433 | Včetně způsobu měření a logickými vazbami mezi (pod)jevy 434 | ![](img/20230603112705.png) 435 | --------------------------------------------------------------------------------