Metodiky vývoje SW. Práce s požadavky a jejich modelování. Styly a vzory.

1. Vize projektu. Tradiční a agilní metodiky vývoje SW. DevOps.
2. 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.
3. 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ů.
4. Obchodní procesy a jejich vztah k požadavkům. Modelování požadavků pomocí UML - diagram aktivit.
5. UML digram případů užití. Scénáře případů užití. Wireframes.
6. UML diagram tříd, diagram stavů. Vazby aggregace a kompozice.
7. UML diagramy nasazení, komponent a sekvencí.
8. Komponentový vývoj, dependency injection, java EE architektura, kontejnery.
9. JavaBeans.
10. Perzistentní vrstva.
11. GRASP, Byznys vrstva.
12. Design Patterny, Prezentační vrstva, testy, základy deployment, maintenance.
13. Softwarová architektura, škálování, SOA.

• 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í 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.

• Unified Process (UP):
  • Rozdělení do fází:
    1. Zahájení (inception) – definice problému, specifikace zadání.
    2. Příprava (elaboration) – zpřesnění požadavků, architektura, prototyp.
    3. Konstrukce (construction) – dokončení návrhu, implementace, testování.
    4. Předání (transition) – finalizace, beta testy, nasazení.
  • V každé fázi probíhá iterace (opakovaný cyklus činností).

• 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.

• 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.

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.

• 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).

• 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…).

• 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.

• 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.

• 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í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.“

• 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…

• 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:
  • 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ů.

• 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).

• 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ěší.

• 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.

• 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).

• Zóny zodpovědnosti (partitions):
  • Označují, kdo je za kterou aktivitu odpovědný (např. oddělení, tým, role).

• 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á.

• 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.

• 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.

• 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.

• 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:
  1. Třída: jméno, atributy, (operace (metody))
  2. Viditelnost členů: public (+), private (-), protected (#), package (~)
  3. Násobnost (multiplicitа): vyjadřuje počet instancí vztahu (např. 1, 0..*, 1..*)
  4. Asociace: spojení mezi třídami, může mít jméno a role
  5. Asociační třída: slouží k přidání atributů nebo operací ke vztahu
• Doporučení:
  1. Používat srozumitelná jména (UpperCamelCase pro třídy, lowerCamelCase pro atributy a metody)
  2. Nepoužívat zkratky

• Agregace
  1. Vyjadřuje vztah celek–část, kde části mohou existovat nezávisle na celku.
  2. Znázorněna prázdným kosočtvercem na straně celku.
  3. Příklad: Počítač obsahuje více periferií, ale periférie existují samostatně.
• Kompozice
  1. Silnější forma agregace, kde části jsou závislé na celku.
  2. Znázorněna plným kosočtvercem na straně celku.
  3. Pokud celek zanikne, zanikají i jeho části (kaskádové mazání).
  4. Příklad: Dům má patra, která bez domu neexistují.

• Slouží k modelování životního cyklu objektů, jejich stavů a přechodů mezi nimi.
• Základní prvky:
  1. Počáteční stav (start) – označený černým bodem.
  2. Stavy – pojmenované bloky, reprezentují různé fáze životního cyklu.
  3. Přechody – šipky označující změnu stavu, často s podmínkou (guard) a akcí.
  4. Konečný stav (end) – označený kroužkem se středem.
• Použití:
  1. Modelování stavů objednávky (nová, zpracovává se, dokončená, zrušená).
  2. Popis reakce systému na události.

• 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)

sincompdiag

• Popisuje fyzické nasazení softwarových komponent na hardware.
• Základní prvky:
  1. Uzly (nodes) – fyzické zařízení (server, počítač, router).
  2. Artefakty (artifacts) – softwarové komponenty nasazené na uzlech (soubor, aplikace).
  3. Vazby – spojení mezi uzly, které znázorňují komunikaci nebo propojení.
• Slouží k plánování a dokumentaci fyzické infrastruktury.

umístění SW na HW (Artefakty)

• 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:
  1. Lifelines – reprezentují objekty nebo instance.
  2. Aktivace – doba, kdy je objekt aktivní (vykonává akci).
  3. Zprávy – synchronní i asynchronní volání metod mezi objekty.
  4. Vytváření a zničení objektů.
  5. 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.
• [Místo pro obrázek UML sekvenčního diagramu – ukázka výměny zpráv mezi objekty]

• 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

• Výhody:
  • Lepší modularita.
  • Oddělení zodpovědností.
  • Snadnější správa závislostí a verzí.

• 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).

• Architektura pro velké podnikové (enterprise) aplikace.
• Typicky vícevrstvá (multi-tier):

• klientské aplikace (web, desktop, jiný server).
• Request – response komunikace

• 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.

• 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.

• 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 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 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.

• 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()).

• 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:
  • 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.

• 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.

• 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.

• 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ě.

• 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ě.

• 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).

• 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.

• JPA entity – reprezentace datových objektů mapovaných do databáze.
• EntityManager – API pro správu perzistence.
• Transakce spravované pomocí JTA (Java Transaction API).

• 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).

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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ě).

• 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.

• Odráží realitu podnikání a doménu aplikace.
• Zajišťuje integritu dat a pravidel.
• Může obsahovat:
  1. Služby (services), které implementují konkrétní obchodní operace.
  2. Validace vstupů a kontrolu konzistence.
  3. Správu transakcí.
• Odděluje doménovou logiku od uživatelského rozhraní a perzistence.

• 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.

• 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.

• Úč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:
  1. Redukuje počet objektů, se kterými klienti komunikují.
  2. Snižuje závislosti mezi klientem a subsystémem (nižší coupling).
  3. 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`.

• Úč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:
  1. Podporuje volnou vazbu mezi objekty (low coupling).
  2. Umožňuje dynamické přidávání a odebírání pozorovatelů za běhu.
  3. 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í.

• Úč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:
  1. Umožňuje nezávislý vývoj modelu, uživatelského rozhraní a ovládání.
  2. Podporuje více pohledů na stejná data (model).
  3. 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.

• Slouží k interakci s uživatelem, poskytuje vizuální reprezentaci dat.
• Typické technologie:
  1. JavaServer Faces (JSF) – komponentový framework pro webová UI.
  2. 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.

• Různé úrovně testování:
  1. Jednotkové testy (unit tests) – testování malých částí kódu izolovaně.
  2. Integrační testy – testování spolupráce komponent.
  3. Systémové testy – testování celého systému.
• Populární testovací nástroje:
  1. JUnit – framework pro jednotkové testy v Javě.
  2. Selenium – automatizace testů uživatelského rozhraní.
• Testovací techniky zahrnují:
  1. Testovací fixturní přípravy (setup/teardown).
  2. Parametrizované testy.
  3. Očekávané výjimky a testování chybových stavů.

• 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í:
  1. Logování a sběr metrik.
  2. Nástroje jako Zabbix, Nagios, Google Analytics.
• Správa verzí a rollback v případě problémů.

• Ú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).

• 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ě:
  1. Styl je konceptuální rámec, jak něco uspořádat.
  2. Architektura je konkrétní návrh podle těchto pravidel pro daný systém.

• 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.

• 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í.

• 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.

• 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.

• Základní způsoby škálování výkonu systému:
  1. Vertikální škálování (scale up): zvětšení výkonu jednoho serveru (silnější HW).
  2. 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:
  1. Client-server
  2. Client-dispatcher-server (přidání dispatcher vrstvy pro distribuci zátěže)
  3. 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ů.

• Architektura založená na službách, kde jsou aplikace rozděleny na nezávislé, znovupoužitelné služby.
• Charakteristiky služeb v SOA:
  1. Volná vazba (loose coupling)
  2. Opakovatelnost (reusability)
  3. Bezstavovost (statelessness)
  4. Autonomie
  5. Objevitelnost (discoverability)
  6. Abstrakce
  7. Skladatelnost (composability)
  8. Platformová nezávislost
• SOA podporuje integraci heterogenních systémů a služeb.

• 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.

• SOA umožňuje lepší podporu obchodních procesů, flexibilitu a rozšiřitelnost systémů.