statnice:bakalar:b4b36sin

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Metodiky vývoje SW. Práce s požadavky a jejich modelová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 <role>, potřebuji <cíl/přání>, protože <přínos>.“*
    * 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 <CO?> (<KOMU?>) (<ZA PODMÍNEK?>) (<PROČ?>).“*
    * 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ř. <<supported>>, <<not supported>>) 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: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 add<Event>Listener a remove<Event>Listener.

==== 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ů.
Trace: • b4b36zui • b4b01dma • b4b35osy • b0b01ma1 • b4b01num • b0b33opt
Search

Navigation

Print/export

Tools

QR Code
