====== Metodiky vývoje SW. Práce s požadavky a jejich modelování. Styly a vzory. ====== - Vize projektu. Tradiční a agilní metodiky vývoje SW. DevOps. - Metodika SCRUM detailně. Role v týmu (Product Owner, SCRUM master,...). Sprint a product backlog. SCRUM události (sprint, sprint planning meeting, demo meeting, retrospectvive meeting, stand-up meeting). Výstupy sprintu. - Byznys cíle, byznys požadavky a systémové požadavky. Textově formulované požadavky a jejich atributy. Zdroje a způsoby získavání požadavků. Kategorizace požadavků. Šablony textově formulovaných požadavků. - Obchodní procesy a jejich vztah k požadavkům. Modelování požadavků pomocí UML - diagram aktivit. - UML digram případů užití. Scénáře případů užití. Wireframes. - UML diagram tříd, diagram stavů. Vazby aggregace a kompozice. - UML diagramy nasazení, komponent a sekvencí. - Komponentový vývoj, dependency injection, java EE architektura, kontejnery. - JavaBeans. - Perzistentní vrstva. - GRASP, Byznys vrstva. - Design Patterny, Prezentační vrstva, testy, základy deployment, maintenance. - Softwarová architektura, škálování, SOA. ===== Vize projektu. Tradiční a agilní metodiky vývoje SW. DevOps ===== ==== Vize projektu ==== * Vize projektu (vision document) je **první krok od „nápadu“ k reálnému produktu**. * Obsahuje: * Jasný, stručný a výstižný popis projektu. * Celkový rozsah projektu. * Hlavní cíle projektu – co chceme dosáhnout? * Přínosy pro zadavatele a koncové uživatele – proč to chceme? * Slouží k rychlému zorientování všech zapojených osob (stakeholders). * Používají se šablony, které obsahují kapitoly jako RACI matice, slovníček pojmů, kvalitativní požadavky, omezení a metriky. ==== Tradiční metodiky vývoje SW ==== * **Tradiční přístup (např. waterfall):** * Lineární postup: analýza → návrh → implementace → testování → nasazení. * Výhody: * Jasný plán a harmonogram. * Snadné řízení zdrojů, přehlednost. * Vhodné i pro méně zkušené týmy. * Nevýhody: * Špatná reakce na změny. * Chyby odhalené až na konci jsou drahé na opravu. * Dlouhá doba, než zákazník vidí výsledky. {{statnice:bakalar:sinwaterfall.png?700}} * **Unified Process (UP):** * Rozdělení do fází: - Zahájení (inception) – definice problému, specifikace zadání. - Příprava (elaboration) – zpřesnění požadavků, architektura, prototyp. - Konstrukce (construction) – dokončení návrhu, implementace, testování. - Předání (transition) – finalizace, beta testy, nasazení. * V každé fázi probíhá iterace (opakovaný cyklus činností). {{statnice:bakalar:sinunified.png?700}} ===== Agilní metodiky ===== * Agilní přístup: * Vyvinutý jako reakce na selhávání tradičních metodik. * **Založený na agilním manifestu (2001):** * Lidé a komunikace > procesy a nástroje. * Fungující software > vyčerpávající dokumentace. * Spolupráce se zákazníkem > přesná smlouva. * Reakce na změnu > striktní plán. * Příklady: * **Scrum** – práce v krátkých sprintech, jasné role (product owner, scrum master, tým). * Extreme Programming (XP) – malé releasy, user stories, test-driven development, pair programming, kontinuální integrace. * Výhody: * Rychlá zpětná vazba. * Flexibilita. * Zapojení zákazníka. * Nevýhody: * Není vhodné pro velké, dislokované týmy. * Vyžaduje zkušené programátory a silnou týmovou spolupráci. {{statnice:bakalar:sinscrum.png?700}} ===== DevOps ===== * DevOps propojuje vývoj (Dev) a provoz (Ops). * **Hlavní myšlenka: „You build it, you run it!“** * Cíle: * Automatizace procesů (build, test, release, monitorování). * Kratší cykly nasazování (continuous integration / continuous delivery, CI/CD). * Lepší spolupráce mezi vývojáři a provozními týmy. * Technologie: * Nástroje jako Jenkins, GitLab CI, Docker, Kubernetes. * GitOps – GIT jako jediný zdroj pravdy nejen pro kód, ale i pro konfiguraci infrastruktury. * DevOps je součástí širšího přístupu cloudových služeb, často navázaný na IaaS, PaaS, SaaS. {{statnice:bakalar:sindevops.png?700}} ===== Metodika SCRUM detailně===== **Role v týmu (Product Owner, SCRUM master,...). Sprint a product backlog. SCRUM události (sprint, sprint planning meeting, demo meeting, retrospectvive meeting, stand-up meeting). Výstupy sprintu.** ==== Základní principy SCRUM ==== * SCRUM je agilní rámec řízení projektů. * Je založený na iteracích zvaných sprinty. * Klade důraz na týmovou spolupráci, transparentnost, rychlou zpětnou vazbu a přizpůsobení se změnám (**viz. agilní manifest - předchozi otazka**). * Cílem je dodat v každém sprintu funkční, připravený produktový přírůstek (increment). ==== Role v týmu ==== * **Product Owner (vlastník produktu)** * Jedna fyzická osoba, která reprezentuje všechny stakeholdery. * Určuje, co se má dělat (co má nejvyšší prioritu), ale ne jak. * Spravuje product backlog (seznam požadavků). * **SCRUM Master** * Facilitátor, zajišťuje, že tým správně používá SCRUM. * Odstraňuje překážky, chrání tým před rušením. * Organizuje schůzky, dohlíží na proces. * **SCRUM Team (vývojový tým)** * Samoorganizující se tým, který realizuje úkoly sprintu. * Nese odpovědnost za dodání funkčního přírůstku. * Obvykle 5–9 lidí, multidisciplinární (vývojáři, testeři, analytici…). === Sprint a Product Backlog === * **Product Backlog** * Seznam všech požadavků, úkolů a vylepšení, které jsou potřeba. * Prioritizovaný Product Ownerem. * Neustále aktualizovaný podle změn a nových požadavků. * **Sprint** * Časově ohraničená iterace (typicky 2–4 týdny). * V jejím rámci tým realizuje vybrané položky z backlogu (sprint backlog). * Během sprintu nejsou povoleny změny v cílech sprintu. === SCRUM události === * **Sprint Planning Meeting (plánování sprintu)** * Na začátku sprintu. * Tým společně s Product Ownerem vybere úkoly pro sprint. * Výstup: sprint backlog a stanovený sprint goal (cíl sprintu). * **Daily Stand-up Meeting (denní stand-up)** * Krátké (cca 15 min) denní setkání celého týmu. * Každý člen zodpoví: * Co jsem udělal včera? * Co budu dělat dnes? * Jaké mám překážky? * **Sprint Review / Demo Meeting** * Na konci sprintu. * Tým předvede dokončený přírůstek (increment) stakeholderům. * Diskuze nad výsledky, zpětná vazba. * **Sprint Retrospective Meeting** * Reflexe po sprintu (po review). * Tým diskutuje, co se povedlo, co by šlo zlepšit. * Plánují se konkrétní zlepšení pro příští sprint. === Výstupy sprintu === * Funkční, integrovaný a otestovaný přírůstek produktu (increment). * Aktualizovaný product backlog. * Seznam poznatků a návrhů na zlepšení ze sprint retrospective. * Lepší týmová spolupráce a efektivnější procesy díky zpětné vazbě. ===== Byznys cíle, byznys požadavky a systémové požadavky. Textově formulované požadavky a jejich atributy. Zdroje a způsoby získavání požadavků. Kategorizace požadavků. Šablony textově formulovaných požadavků. ===== ==== Byznys cíle, byznys požadavky a systémové požadavky ==== * **Byznys cíl (business goal)** * Strategické směřování organizace. * Definuje, **čeho má organizace dosáhnout** (např. zvýšení tržeb, zlepšení kvality). * **Byznys požadavek (business requirement)** * Popisuje, čeho má změna dosáhnout a jak měřit její úspěch. * Odpovídá na otázku, **proč má být změna realizována.** * Např. „Jako manažer potřebuji zpracovat data o tržbách pro výpočet profitability.“ * **Systémový požadavek (system requirement)** * **Popisuje chování IT řešení**, jeho omezení (výkon, bezpečnost). * Reaguje na byznys požadavky a IT architekturu. * Např. „Systém bude umožňovat export tabulek do CSV.“ ==== Textově formulované požadavky a jejich atributy ==== * **Atributy požadavků:** * Jednoznačný identifikátor. * Název. * Popis. * Zdroj/zadavatel. * Priorita. * Doplňkově: autor, odhad složitosti, rizika, stabilita, stav, naléhavost. * **Pravidla:** * Používej strukturovaný text. * Jeden požadavek = jedna formulace. * Vyhýbej se složitým souvětím. * Používej srozumitelnou terminologii. * Nepiš trpným rodem. * Ověřuj univerzální kvantifikátory (např. „všichni“, „nikdy“). * Popisuj CO, ne JAK. * Používej šablony. Mohou být dokumentovány jako volný nebo struktorovaný text, tabulky, grafy... ==== Šablony textově formulovaných požadavků ==== * **Pro byznys požadavky:** * *„Jako , potřebuji , protože .“* * Např. „Jako obchodník potřebuji být informován o končících smlouvách, abych mohl začít včas jednat.“ * **Pro systémové požadavky:** * *„Systém bude umožňovat () () ().“* * Např. „Systém umožní manažerovi přidat novou směnu.“ ==== Zdroje a způsoby získávání požadavků ==== * **Zdroje:** * Zainteresované osoby (stakeholders) – zákazníci, uživatelé, analytici, administrátoři, regulátoři. * Dokumentace (legislativa, manuály, normy). * Stávající systémy a procesy. * Trh a konkurence. * **Techniky sběru:** * Individuální rozhovory. * Skupinová jednání. * Analýza dokumentů. * Pozorování (aktivní, pasivní). * Brainstorming. * Dotazníky. * Prototypování. * Modelování procesů. ==== Kategorizace požadavků ==== * **Funkční požadavky (Functional Requirements)** * Co systém umožňuje uživatelům. * **Nefunkční požadavky (Non-functional Requirements)** * Kvalita systému: výkon, spolehlivost, bezpečnost, uživatelská přívětivost. * **Přechodné požadavky (Transitional Requirements)** * Dočasné požadavky související se zaváděním řešení (školení, migrace dat). ==== Kategorizace podle Kano modelu ==== * **Nutné vlastnosti (Dissatisfiers)** – samozřejmé, nesplnění = nespokojenost. * **Požadované vlastnosti (Satisfiers)** – explicitně zmíněné, očekávané. * **Zbytné vlastnosti (Delighters)** – neočekávané, ale potěší. {{statnice:bakalar:sinkano.png?700}} ===== Obchodní procesy a jejich vztah k požadavkům. Modelování požadavků pomocí UML - diagram aktivit. ===== ==== Obchodní procesy a jejich vztah k požadavkům ==== * **Obchodní (business) procesy:** * Uspořádané činnosti, které společně realizují podnikatelský nebo strategický cíl. * Příklad: proces zahrnující objednávku, výrobu a doručení produktu. * **Pohledy na procesy:** * AS IS – jak procesy aktuálně fungují. * TO BE – jak by měly fungovat po zavedení změny nebo systému. * (AS MANAGEMENT THINKS IT IS – jak si vedení myslí, že aktuálně fungují.) * **Proč popisujeme business procesy:** * Pro tvorbu nabídky (identifikace, co systém bude podporovat). * Pro detailní analýzu systému a jeho požadavků. * Pro reengineering a zlepšení procesů. * Pro školení a testování (tutory i testery zajímá nejen menu, ale i smysl systému). * **Vazba na požadavky:** * Business procesy jsou klíčovým zdrojem funkčních i nefunkčních požadavků. * Pochopení procesů pomáhá přesněji formulovat systémové požadavky. ==== Modelování požadavků pomocí UML – diagram aktivit ==== * **UML diagram aktivit:** * Grafická reprezentace procesů, která je rychleji pochopitelná než text. * Vizualizuje tok činností, rozhodování, paralelní běhy a odpovědnosti. * **Klíčové prvky diagramu aktivit:** * Startovní uzel (počátek procesu). * Akční uzly (konkrétní činnosti). * Rozhodovací uzly (větvení podle podmínek). * Sloučení (merge) a rozvětvení (fork) uzly. * Paralelní běhy (více větví probíhá současně). * Koncové uzly (ukončení aktivity nebo jen větve). {{statnice:bakalar:sinact.png?500}} {{statnice:bakalar:sinfork.png?300}} {{statnice:bakalar:sinpar.png?400}} * Zóny zodpovědnosti (partitions): * Označují, kdo je za kterou aktivitu odpovědný (např. oddělení, tým, role). {{statnice:bakalar:sinzone.png?700}} * **Použití:** * K zachycení business procesů (AS IS, TO BE). * Pro analýzu a návrh systému. * Pro komunikaci s klientem – klient často lépe pochopí grafický než textový popis. * **Specifika:** * Diagramy lze doplnit vstupy/výstupy (object nodes). * Lze znázornit signály a časové události (např. časové čekání, odeslání/přijetí zprávy). * Stereotypy (např. <>, <>) mohou vyznačovat, co systém pokrývá. {{statnice:bakalar:sinstereo.png?700}} ===== UML digram případů užití. Scénáře případů užití. Wireframes. ===== === UML diagram případů užití (Use Case Diagram) === * Slouží k zachycení funkčních požadavků systému z pohledu uživatelů (aktérů). * Zobrazuje: * Aktéry (uživatele nebo jiné systémy), kteří interagují se systémem. * Případy užití (use cases) – jednotlivé funkce nebo procesy, které systém poskytuje. * Vztahy mezi aktéry a případy užití. * Cíl: vymezit hranice systému a základní funkce, které systém umožňuje. {{:statnice:bakalar:sinusecase1.png?400}}{{:statnice:bakalar:sinusecase2.png?300}} === Scénáře případů užití (Use Case Scenarios) === * Podrobný popis interakce mezi uživatelem a systémem během realizace případu užití. * Typy scénářů: * **Hlavní (happy flow)** – ideální průběh bez chyb a výjimek. * **Alternativní** – odlišné průběhy, např. volitelné kroky nebo rozdělení toku. * **Výjimečný (exceptional)** – zpracování chybových stavů nebo výjimek. * Scénáře popisují posloupnost kroků, vstupy a výstupy. {{:statnice:bakalar:sinusecasescenario.png?900}} === Wireframes === * Návrhové schematické nákresy uživatelských obrazovek nebo rozhraní. * Slouží k vizualizaci struktury a rozložení UI prvků bez zaměření na grafiku. * Pomáhají při komunikaci s klienty, designéry a vývojáři. * Usnadňují plánování uživatelských interakcí a navigace v aplikaci. {{:statnice:bakalar:sinwireframe.png?900}} ===== UML diagram tříd, diagram stavů. Vazby aggregace a kompozice. ===== ==== UML diagram tříd ==== * UML diagram tříd je statický diagram, který modeluje strukturu systému. * Zachycuje třídy, jejich atributy, metody a vztahy mezi nimi. * **Klíčové prvky: ** - Třída: jméno, atributy, (operace (metody)) - Viditelnost členů: public (+), private (-), protected (#), package (~) - Násobnost (multiplicitа): vyjadřuje počet instancí vztahu (např. 1, 0..*, 1..*) - Asociace: spojení mezi třídami, může mít jméno a role - Asociační třída: slouží k přidání atributů nebo operací ke vztahu * Doporučení: - Používat srozumitelná jména (UpperCamelCase pro třídy, lowerCamelCase pro atributy a metody) - Nepoužívat zkratky {{statnice:bakalar:sinclass.png?900}} ==== Vazby agregace a kompozice ==== * **Agregace** - Vyjadřuje vztah celek–část, kde části mohou existovat nezávisle na celku. - Znázorněna prázdným kosočtvercem na straně celku. - Příklad: Počítač obsahuje více periferií, ale periférie existují samostatně. * **Kompozice** - Silnější forma agregace, kde části jsou závislé na celku. - Znázorněna plným kosočtvercem na straně celku. - Pokud celek zanikne, zanikají i jeho části (kaskádové mazání). - Příklad: Dům má patra, která bez domu neexistují. {{statnice:bakalar:sinaggr.png?500}} {{statnice:bakalar:sincomp.png?500}} ==== UML diagram stavů (State Diagram) ==== * Slouží k modelování životního cyklu objektů, jejich stavů a přechodů mezi nimi. * Základní prvky: - Počáteční stav (start) – označený černým bodem. - Stavy – pojmenované bloky, reprezentují různé fáze životního cyklu. - Přechody – šipky označující změnu stavu, často s podmínkou (guard) a akcí. - Konečný stav (end) – označený kroužkem se středem. * Použití: - Modelování stavů objednávky (nová, zpracovává se, dokončená, zrušená). - Popis reakce systému na události. {{statnice:bakalar:sinstate.png?500}} ===== UML diagramy nasazení, komponent a sekvencí. ===== ==== UML diagram komponent ==== * Popisuje logickou architekturu systému – rozdělení na moduly a subsystémy. * Základním prvkem je komponenta (component), což je černá skříňka s definovanými rozhraními. * Komponenty mají poskytovaná (provided) a požadovaná (required) rozhraní, které definují jejich chování a závislosti. * Komponenta může obsahovat další komponenty, takže umožňuje hierarchickou strukturu (viz. obrázek, celý systém je také komponenta) {{:statnice:bakalar:sincompdiag.png?700}} ==== UML diagram nasazení (Deployment Diagram) ==== * Popisuje fyzické nasazení softwarových komponent na hardware. * Základní prvky: - Uzly (nodes) – fyzické zařízení (server, počítač, router). - Artefakty (artifacts) – softwarové komponenty nasazené na uzlech (soubor, aplikace). - Vazby – spojení mezi uzly, které znázorňují komunikaci nebo propojení. * Slouží k plánování a dokumentaci fyzické infrastruktury. {{:statnice:bakalar:sindeploy.png?900}} **umístění SW na HW (Artefakty)** {{:statnice:bakalar:sinswhw1.png?700}}{{:statnice:bakalar:sinswhw2.png?700}} ==== UML sekvenční diagram (Sequence Diagram) ==== * Modeluje časovou posloupnost interakcí mezi objekty nebo komponentami. * Zobrazuje, jaké zprávy jsou mezi objekty posílány a v jakém pořadí. * Základní prvky: - Lifelines – reprezentují objekty nebo instance. - Aktivace – doba, kdy je objekt aktivní (vykonává akci). - Zprávy – synchronní i asynchronní volání metod mezi objekty. - Vytváření a zničení objektů. - Kombinované fragmenty (alt, opt, loop) pro podmíněné a opakované chování. * Používá se pro detailní analýzu chování systému a komunikace mezi komponentami. {{:statnice:bakalar:sinseqadd.png?500}}{{:statnice:bakalar:sinseqdel.png?500}} {{:statnice:bakalar:sinseq.png?600}} {{:statnice:bakalar:sinseq1.png?700}} ===== Komponentový vývoj, dependency injection, java EE architektura, kontejnery. ===== ==== Komponentový vývoj ==== * Přístup k vývoji softwaru, kde aplikace vzniká skládáním předpřipravených komponent. * **Komponenta:** * Funkční blok s jasně definovaným rozhraním. * **Může být jednoduchý objekt, kolekce objektů nebo modul.** * Podporuje znovupoužitelnost, snadnější údržbu a testování. **Objekt vs Komponenta:** *Objekt: identity oriented – doménová abstrakce *Komponenta: orientace na služby(service oriented) - funkční abstrakce {{statnice:bakalar:sinkompvsobj.png?500}} * Výhody: * Lepší modularita. * Oddělení zodpovědností. * Snadnější správa závislostí a verzí. ==== Dependency Injection (DI) ==== * Technika pro předávání závislostí mezi komponentami. * **Spousta komponentů musí být nějak propojena.** * Komponenta nevyhledává své závislosti sama, ale dostává je zvenku (od frameworku/kontejneru). * Přínosy: * Snížení závislosti mezi komponentami (loosely coupled). * Snadnější testování (možnost snadno podstrčit závislosti). * Lepší správa životního cyklu objektů. * V Java EE realizováno pomocí Contexts and Dependency Injection (CDI). {{statnice:bakalar:sindi.png?700}} ==== Java EE architektura ==== * Architektura pro velké podnikové (enterprise) aplikace. * Typicky vícevrstvá (multi-tier): ===Client tier=== * klientské aplikace (web, desktop, jiný server). * Request – response komunikace === Web tier === * Komponenty, které zajišťují komunikaci mezi klientem a business tierem. * Hlavní úlohy: * Dynamické generování obsahu (HTML, XML, JSON). * Sběr vstupů od uživatele a předání výsledků. * Řízení toku aplikace. * Udržování stavu uživatelské relace. * Používané Java EE technologie: * Servlets – třídy, které dynamicky zpracovávají požadavky a vracejí odpověď v HTML. * Java ServerFaces (JSF) – framework pro uživatelská rozhraní webových aplikací, obsahuje UI komponenty, zajišťuje validaci a správu stavu. * Facelets – šablonovací systém pro XHTML. * Expression Language – umožňuje odkazovat se na Java EE komponenty z JSP/Facelets. * Java Server Pages (JSP) – textové dokumenty kompilované na servlety, které definují dynamický obsah přidaný do statických stránek. * JSP Tag Library – knihovna základních funkcí a tagů. * JavaBeans Components – objekty, které slouží jako dočasné úložiště dat pro aplikaci. === Business tier === * Komponenty, které poskytují business logiku aplikace. * Obsahují klíčové funkce aplikace, např. pro finančnictví, e-commerce, správu uživatelů. * Používané Java EE technologie: * Enterprise JavaBeans (EJB) – komponenty, které zapouzdřují hlavní funkce aplikace. * JAX-RS RESTful web service endpoints – API pro vytváření webových služeb nad HTTP (REST). * JAX-WS web service endpoints – vytváření a konzumace SOAP webových služeb. * Java Persistence API entities – API pro přístup k datům v úložištích a mapování na Java objekty. * Java EE managed beans – řízené komponenty, které poskytují business logiku, ale nevyžadují transakce nebo bezpečnostní funkce EJB. * Lehké POJO (Plain Old Java Object) s minimálními požadavky. * Malá sada základních služeb. === Enterprise Information System (EIS) tier === * Typicky zahrnuje databázové servery, systémy pro plánování zdrojů, starší datové zdroje atd. * Tyto zdroje jsou obvykle distribuovány na jiných strojích než Java EE server a jsou přístupné přes komponenty business tieru. * Používané Java EE technologie: * Java Database Connection API (JDBC) – nízkoúrovňové API pro přístup a načítání dat z úložišť (např. SQL databáze). * Java Persistence API (JPA) – přístup k podkladovým datovým úložištím přes Java objekty, postavené nad JDBC. * Java EE Connector Architecture (JCA) – API pro připojení k podnikovým zdrojům (např. ERP, CRM systémy). * Java Transition API (JTA) – API pro definici a správu transakcí, včetně distribuovaných transakcí přes více datových zdrojů. ==== Kontejnery v Java EE ==== * Kontejnery poskytují prostředí pro běh komponent a správu jejich životního cyklu. * Typy kontejnerů: * Web container: * Spravuje servlety, JSP, JSF. * Řídí komunikaci mezi klientem a serverem. * EJB container: * Spravuje Enterprise JavaBeans. * Zajišťuje transakce, bezpečnost, škálování. * Application client container: * Spravuje klientské aplikace, které přistupují k Java EE serveru. * Kontejnery: * Poskytují služby jako dependency injection, bezpečnost, transakce, perzistenci. * Umožňují vývojářům soustředit se na logiku aplikace místo správy infrastruktury. ===== JavaBeans ===== ==== Co jsou JavaBeans ==== * JavaBeans jsou opakovaně použitelné softwarové komponenty v jazyce Java. * Umožňují vývojářům používat komponenty jiných autorů, aniž by museli znát jejich vnitřní implementaci. * Jsou navrženy tak, aby se daly snadno používat v nástrojích pro vizuální návrh. ==== Základní vlastnosti JavaBean komponenty ==== * Je to **běžná Java třída (class).** * Musí mít: * **veřejný (public) konstruktor bez parametrů.** * podporu **serializace **(implementace rozhraní Serializable). * přístup k vlastnostem přes metody **getter a setter** (např. getName(), setName()). === Typy vlastností === * **Simple properties** – jednoduché hodnoty přístupné přes get/set. * **Boolean properties** – místo get používají is (např. isRunning()). * **Bound properties** – komponenta oznamuje změnu hodnoty posluchačům (PropertyChangeListener). * **Constrained properties** – změna hodnoty může být vetována posluchačem (VetoableChangeListener). === Metody a události === * **Metody:** * Veřejné metody komponenty, které neslouží přímo k přístupu k vlastnostem. * **Události:** * Komponenta může vyvolávat různé typy událostí (např. ActionEvent). * Posluchači (listeners) jsou přidáváni a odebíráni metodami addListener a removeListener. ==== Persistování stavu (Persistence) ==== * JavaBeans **musí podporovat uložení a načtení svého stavu.** * **Serializace:** * Standardní způsob, jak uložit objekt do proudu dat. * Implementace pomocí Serializable. * Ovládání(modifikace) serializace: * Použití transient modifikátoru pro vyloučení polí ze serializace. * Použití Externalizable pro vlastní formát zápisu. * **Dlouhodobé uložení:** * Ukládání ve formátu **XML** pomocí tříd XMLEncoder a XMLDecoder. === Shrnutí výhod JavaBeans === * Snadná integrace do vývojových nástrojů. * Opakovatelné použití komponent. * Standardizované pojmenování metod (getter/setter). * Podpora událostí, posluchačů a práce s vlastnostmi. ===== Perzistentní vrstva ===== ==== Úloha perzistentní vrstvy ==== * Zajišťuje trvalé uložení dat, která aplikace používá. * Odděluje obchodní logiku od detailů ukládání a načítání dat. * Umožňuje aplikaci pracovat s daty nezávisle na konkrétní implementaci úložiště. {{statnice:bakalar:sinpers.png?250}} ==== Object-Relational Mapping (ORM) ==== * Technika mapování objektově orientovaných modelů na relační databáze. * Řeší problém **„paradigm mismatch“ mezi objekty a relačními tabulkami.** * Podporuje dědičnost, asociace, laziness načítání, kaskádování a transakce. * Příklady implementací: Hibernate, EclipseLink. * **JPA (Java Persistence API)** – standardní API pro ORM v Javě. ==== Typické funkce perzistentní vrstvy ==== * **CRUD operace (Create, Read, Update, Delete).** * **Správa transakcí a konzistence dat.** * Podpora složitých dotazů (např. JPQL, Criteria API). * **Optimalizace výkonu (cache, lazy loading).** === Design Patterns v perzistentní vrstvě === * **Data Access Object (DAO)** * Poskytuje rozhraní pro přístup k datům. * Izoluje logiku přístupu k datům od zbytku aplikace. * **Repository** * Abstrakce nad DAO, zaměřená na práci s agregáty domény. * **Unit of Work** * Sleduje změny v entitách během transakce a koordinuje jejich zápis. === Příklady z Java EE === * **JPA entity** – reprezentace datových objektů mapovaných do databáze. * EntityManager – API pro správu perzistence. * Transakce spravované pomocí JTA (Java Transaction API). ===== GRASP, Byznys vrstva ===== ==== GRASP (General Responsibility Assignment Software Patterns) ==== === Co je GRASP === * **Soubor design patternů** pro přiřazování odpovědností objektům v objektově orientovaném designu. * Pomáhají řešit otázky:** Které objekty/co by mělo vykonávat jaké úkoly a jak spolu mají spolupracovat.** * Cílem je vytvořit návrh s nízkou závislostí (low coupling) a vysokou soudržností (high cohesion). === Klíčové GRASP vzory === * **Information Expert** * Jaký problém řeší: Které třídě přidělit odpovědnost za určitý úkol, aby měla potřebné informace pro jeho splnění. * (Způsob řešení): Přidělit odpovědnost třídě, která obsahuje nejvíce informací potřebných k vykonání daného úkolu. {{statnice:bakalar:sininfex.png?500}} * **Creator ** * Jaký problém řeší: Kdo by měl být odpovědný za vytvoření nové instance určité třídy. * (Způsob řešení): Přidělit odpovědnost za vytvoření nové instance třídě, která tuto instanci používá, obsahuje, nebo má data potřebná k její inicializaci. {{statnice:bakalar:sincreator.png?500}} * **Low Coupling** * Jaký problém řeší: Minimalizace závislostí mezi třídami, aby změny měly co nejmenší dopad. * (Způsob řešení): Navrhnout systém tak, aby třídy měly co nejméně přímých závislostí na ostatních třídách. {{statnice:bakalar:sinlowcopbad.png?500}}{{statnice:bakalar:sinlowcopgood.png?500}} * **High Cohesion ** * Jaký problém řeší: Udržení třídy zaměřené na úzký okruh odpovědností, aby byla snadno pochopitelná a udržovatelná. * (Způsob řešení): Přiřadit třídě odpovědnosti, které spolu souvisí a jsou logicky propojené. * **Controller** * Jaký problém řeší: Kdo má přijímat a zpracovávat systémové události (např. uživatelské vstupy). * (Způsob řešení): Vybrat objekt, který reprezentuje use case nebo systém, který bude řídit tok událostí a koordinovat další objekty. * **Polymorphism** * Jaký problém řeší: Jak flexibilně přidělit chování na základě typů objektů bez množství podmínek v kódu. * (Způsob řešení): Použít polymorfismus, kde každá třída implementuje vlastní verzi požadované operace. {{statnice:bakalar:sinpoly.png?500}} * **Pure Fabrication ** * Jaký problém řeší: Jak snížit závislosti (coupling) a zvýšit soudržnost (cohesion), když přidělení odpovědností doménovým třídám není vhodné. * (Způsob řešení): Vytvořit pomocnou, umělou třídu, která nebude součástí domény, ale pomůže s odpovědnostmi a strukturou kódu. {{statnice:bakalar:sinpf.png?500}} * **Indirection** * Jaký problém řeší: Jak snížit přímé závislosti mezi objekty. * (Způsob řešení): Zavést zprostředkující objekt (delegáta), který přebírá komunikaci mezi ostatními objekty. {{statnice:bakalar:sinindir.png?500}} * Don't Talk to Strangers (Law of Demeter) * Jaký problém řeší: Omezit přímou komunikaci mezi objekty, které by si neměly být navzájem známy. * (Způsob řešení): Objekty komunikují pouze s objekty, které jsou jim přímo známy (vlastní atributy, parametry, vytvořené objekty v metodě). {{statnice:bakalar:sindemeter.png?500}} ==== Byznys vrstva (Business Layer) ==== === Úloha byznys vrstvy === * Obsahuje obchodní logiku aplikace (business rules, workflow, validace). * Definuje pravidla, jak se s daty pracuje, jak se rozhoduje a jaké procesy se vykonávají. * Odpovídá za koordinaci činností mezi perzistentní a prezentační vrstvou. === Charakteristiky byznys vrstvy === * Odráží realitu podnikání a doménu aplikace. * Zajišťuje integritu dat a pravidel. * Může obsahovat: - **Služby (services)**, které implementují konkrétní obchodní operace. - **Validace vstupů a kontrolu konzistence.** - Správu transakcí. * **Odděluje doménovou logiku od uživatelského rozhraní a perzistence.** {{statnice:bakalar:sinbusinessl.png?500}} === Příklad z Java EE === * Enterprise JavaBeans (EJB) jako implementace byznys komponent. * Business services, které provádějí operace nad daty (např. výpočty, kontrola pravidel). * Koordinace volání mezi DAO (přístup k datům) a prezentační vrstvou. === Výhody oddělení byznys vrstvy === * Lepší modularita a srozumitelnost. * Snazší testovatelnost (možnost izolovat obchodní logiku). * Možnost opakovaného použití business služeb v různých aplikacích. * Snazší údržba a rozšiřitelnost systému. ===== Design Patterny, Prezentační vrstva, testy, základy deployment, maintenance ===== ==== Design Patterny ==== === Facade (Fasáda) === * Účel: Poskytuje sjednocené, jednoduché a vysoceúrovňové rozhraní k subsystému, čímž zjednodušuje jeho používání a skrývá složitost implementace. * Výhody: - Redukuje počet objektů, se kterými klienti komunikují. - Snižuje závislosti mezi klientem a subsystémem (nižší coupling). - Umožňuje změny uvnitř subsystému bez vlivu na klienty. * Příklad: Univerzální ovladač, který ovládá více zařízení (projektor, DVD přehrávač, žaluzie) pomocí jednoduchých funkcí jako „přehrát film“ nebo „vypnout hudbu“. Nebo třída `Compiler`, která poskytuje metody pro kompilaci využívající interní třídy `Scanner`, `Parser` a `ProgramNodeBuilder`. {{statnice:bakalar:sinfacade.png?500}} === Observer === * Účel: Umožňuje objektům (pozorovatelům) být automaticky upozorněny na změny stavu jiného objektu (subjektu), aniž by byly pevně vázány na tento objekt. * Výhody: - Podporuje volnou vazbu mezi objekty (low coupling). - Umožňuje dynamické přidávání a odebírání pozorovatelů za běhu. - Podporuje architektury založené na událostech a notifikacích. * Příklad: Hodiny (`ClockTimer`) jako subjekt informující více zobrazení (`DigitalClock`, `AnalogClock`) o změně času, aby mohly aktualizovat zobrazení. {{statnice:bakalar:sinobserver.png?500}} === Model-View-Controller (MVC) === * Účel: Odděluje data (model), uživatelské rozhraní (view) a řízení toku dat a akcí (controller), čímž zlepšuje modularitu a usnadňuje údržbu aplikací s UI. * Výhody: - Umožňuje nezávislý vývoj modelu, uživatelského rozhraní a ovládání. - Podporuje více pohledů na stejná data (model). - Usnadňuje testování a opakované použití komponent. * Příklad: Webová aplikace, kde model uchovává data, view je HTML stránka zobrazující data, a controller zpracovává uživatelské vstupy a aktualizuje model i view. Frameworky jako JavaServer Faces (JSF) implementují MVC architekturu. {{statnice:bakalar:sinmvc.png?500}} ==== Prezentační vrstva (Presentation Layer) ==== * Slouží k interakci s uživatelem, poskytuje vizuální reprezentaci dat. * Typické technologie: - JavaServer Faces (JSF) – komponentový framework pro webová UI. - Swing – pro desktopové aplikace. * Architektura prezentační vrstvy často používá komponentový strom a design patterns jako Composite. * Umožňuje snadné propojení UI komponent s datovými zdroji a obslužnými metodami. * Používá MVC nebo jiné varianty jako PAC, MVP. ==== Testy ==== * Různé úrovně testování: - Jednotkové testy (unit tests) – testování malých částí kódu izolovaně. - Integrační testy – testování spolupráce komponent. - Systémové testy – testování celého systému. * Populární testovací nástroje: - JUnit – framework pro jednotkové testy v Javě. - Selenium – automatizace testů uživatelského rozhraní. * Testovací techniky zahrnují: - Testovací fixturní přípravy (setup/teardown). - Parametrizované testy. - Očekávané výjimky a testování chybových stavů. ==== Základy deploymentu ==== * Deployment znamená nasazení aplikace do provozního prostředí. * Vyžaduje přípravu prostředí (server, databáze, konfigurace). * Automatizace nasazení pomocí CI/CD pipeline (např. Jenkins, GitLab CI). * Monitorování aplikace po nasazení: - Logování a sběr metrik. - Nástroje jako Zabbix, Nagios, Google Analytics. * Správa verzí a rollback v případě problémů. ==== Údržba (Maintenance) ==== * Údržba je klíčová fáze životního cyklu softwaru – zahrnuje opravy chyb, vylepšování a adaptaci. * Prevence chyb pomocí dobrého návrhu, design patterns a testování. * Monitorování zdrojů (paměť, CPU, disky) a prevence úniků paměti. * Používání nástrojů pro profilování, analýzu paměti a výkonu. * Dokumentace a sledování změn (bug tracking, issue management). ===== Softwarová architektura, škálování, SOA ===== ==== Softwarová architektura ==== === Rozdíl mezi architektonickým stylem a softwarovou architekturou === * **Architektonický styl** je obecný vzor, který definuje základní principy, pravidla a strukturu, jakým způsobem jsou komponenty systému uspořádány a jak spolu komunikují. * **Softwarová architektura** je konkrétní realizace systému, která využívá jeden nebo více architektonických stylů a obsahuje konkrétní komponenty, moduly, vztahy a další rozhodnutí. * Zjednodušeně: - Styl je konceptuální rámec, jak něco uspořádat. - Architektura je konkrétní návrh podle těchto pravidel pro daný systém. === Hlavní architektonické styly === * **Data-centric (datově orientovaný styl)** * Zaměřuje se na centralizovanou správu dat a jejich integraci. * Typické systémy: databázové aplikace, hlasové rozpoznávání, kompilátory. * Vlastnosti: škálovatelnost, nízká závislost, centralizace, snadná modifikace. {{statnice:bakalar:sindatacentric.png?500}} * **Call and Return (volání a návrat)** * Komponenty komunikují synchronními voláními metod nebo procedur. * Typicky vrstvená architektura, objektově orientované systémy, RPC, AOP. * Vlastnosti: modularita, snadná údržba, jasná dekompozice funkcí. {{statnice:bakalar:callnret.png?500}} * **Implicit Invocation (událostní řízení)** * Komponenty komunikují prostřednictvím vysílání a přijímání událostí. * Umožňuje volné propojení mezi komponentami. * Používá se v GUI systémech, distribuovaných systémech. {{statnice:bakalar:sinimplin.png?500}} * **Independent Components (nezávislé komponenty)** * Systém je rozložen na autonomní komponenty, které komunikují asynchronně. * Používá se v peer-to-peer, distribuovaných systémech. * Výhody: škálovatelnost, spolehlivost, opakovatelnost. * **Virtual Machines (virtuální stroje)** * Systém je implementován jako vrstva abstrakce nad hardwarovou platformou. * Výhody: přenositelnost, flexibilita. * Nevýhody: nižší výkon. * **Pipes and Filters (průtokové filtry)** * Data procházejí přes řadu nezávislých zpracovatelských kroků (filtrů). * Výhody: jednoduchost návrhu, snadná rozšiřitelnost. * Nevýhody: možné omezené možnosti koordinace mezi filtry, výkonová náročnost. {{statnice:bakalar:sinpipe.png?500}} ==== Škálování (Scaling) ==== * Základní způsoby škálování výkonu systému: - Vertikální škálování (scale up): zvětšení výkonu jednoho serveru (silnější HW). - Horizontální škálování (scale out): přidání více serverů (clusterování). * Problémy s výkonem a škálováním často řešíme cache, optimalizací dotazů, vyvažováním zátěže. * Příklady architektur: - Client-server - Client-dispatcher-server (přidání dispatcher vrstvy pro distribuci zátěže) - Content Delivery Network (CDN) pro rychlé doručení statického obsahu. * Databáze jsou často výkonovým úzkým hrdlem; používá se replikace, datagrid, optimalizace dotazů. {{statnice:bakalar:sincds.png?500}} ==== Service-Oriented Architecture (SOA) ==== * Architektura založená na službách, kde jsou aplikace rozděleny na nezávislé, znovupoužitelné služby. * Charakteristiky služeb v SOA: - Volná vazba (loose coupling) - Opakovatelnost (reusability) - Bezstavovost (statelessness) - Autonomie - Objevitelnost (discoverability) - Abstrakce - Skladatelnost (composability) - Platformová nezávislost * SOA podporuje integraci heterogenních systémů a služeb. {{:statnice:bakalar:sinservice.png?500}} * Komunikace probíhá prostřednictvím zpráv (např. SOAP, REST, JSON, XML). * Enterprise Service Bus (ESB) – middleware pro orchestraci a správu služeb. {{:statnice:bakalar:sinesb.png?500}} * SOA umožňuje lepší podporu obchodních procesů, flexibilitu a rozšiřitelnost systémů.