4IT216 — Analýza a návrh informačních systémů

O předmětu

Předmět pokrývá celý proces analýzy a návrhu informačních systémů — od sběru požadavků přes modelování (UML, DFD, ERD) až po architektonické vzory a návrh databází a API. Klade důraz na systematické postupy a praktické dovednosti.

1. Inženýrství požadavků (Requirements Engineering)

Typy požadavků

Funkční požadavky: Co systém dělá.

• "Systém umožní uživateli zaregistrovat se pomocí emailu a hesla"
• "Administrátor může deaktivovat uživatelský účet"

Nefunkční požadavky (Quality Attributes):

Kategorie	Příklady
Výkon (Performance)	Odpověď < 200ms při 100 souběžných uživatelích
Bezpečnost (Security)	Hesla ukládána jako bcrypt hash, HTTPS povinný
Dostupnost (Availability)	99.9% uptime (max 8.7h výpadku/rok)
Škálovatelnost	Zvládne 10× nárůst uživatelů bez redesignu
Udržovatelnost	Kód splňuje SonarQube Quality Gate
Přenositelnost	Běží na Linux i Windows

Use Cases (případy užití)

Diagram Use Case: Zobrazuje aktéry a jejich interakce se systémem.

        ┌────────────────────────────────────┐
        │           Knihovní systém           │
        │                                    │
  ┌──┐  │  ○ Vyhledat knihu                  │
  │  │──┼─→ ○ Vypůjčit knihu                 │
  │Čtenář│  ○ Vrátit knihu                   │
  └──┘  │  ○ Prodloužit výpůjčku             │
        │                                    │
  ┌──┐  │  ○ Přidat knihu do katalogu        │
  │  │──┼─→ ○ Spravovat uživatele            │
  │Knihovník│ ○ Generovat přehledy            │
  └──┘  └────────────────────────────────────┘

Specifikace Use Case:

• Název, aktéři, předpoklady (preconditions)
• Základní tok (happy path)
• Alternativní toky (extensions)
• Výjimky (exception flows)
• Postconditions

User Stories

Agilní formát: "Jako [role], chci [funkce], abych [benefitt]"

Příklady:

• "Jako zákazník, chci vidět historii svých objednávek, abych mohl sledovat doručení."
• "Jako administrátor, chci exportovat data uživatelů do CSV, abych mohl provádět analýzy."

Kritéria přijetí (Acceptance Criteria): Konkrétní podmínky splnění — BDD formát:

Given [kontext]
When [akce]
Then [výsledek]

Příklad:
Given uživatel je přihlášen
When klikne na "Export CSV"
Then systém stáhne soubor s daty všech uživatelů ve formátu ISO-8601

INVEST kritéria pro dobré user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

2. Strukturovaná analýza

DFD — Data Flow Diagrams

Zobrazuje toky dat mezi procesy, externími entitami a datovými úložišti.

Symboly (Yourdon-DeMarco notace):

• Obdélník = externí entita (zákazník, dodavatel)
• Zaoblený obdélník/bublina = proces
• Dvě rovnoběžné čáry = datové úložiště
• Šipka s popiskem = tok dat

Kontextový diagram (úroveň 0): Celý systém jako jeden proces, všechny externí entity.

Diagram úrovně 1: Rozložení systému na hlavní subsystémy.

Balancování: Vstupy/výstupy procesu na úrovni n musí odpovídat na úrovni n+1.

ERD — Entity-Relationship Diagram

Modeluje datovou strukturu.

Cardinality notations (Crow's Foot):

Zákazník ||──o{ Objednávka
           "jeden zákazník má nula nebo více objednávek"

Objednávka }o──|| Zákazník
           "objednávka patří právě jednomu zákazníkovi"

Typy vztahů:

• 1:1 (jeden k jednomu)
• 1:N (jeden k mnoha)
• M:N (mnoho k mnoha) → rozkladná tabulka

Silné vs. slabé entity: Slabá entita nemá vlastní primární klíč — závisí na silné entitě.

3. Objektově orientovaná analýza — UML

Class Diagram (diagram tříd)

┌─────────────────────┐
│ <>        │
│ Osoba               │
├─────────────────────┤
│ - jmeno: String     │
│ - email: String     │
├─────────────────────┤
│ + getPrijmeni(): Str│
│ + isActive(): bool  │
└─────────┬───────────┘
          │ <>
    ┌─────┴──────┐
    │            │
┌───┴──┐   ┌────┴──┐
│Zákaznk│   │Zaměstnc│
└──────┘   └───────┘

Vztahy v UML:

Vztah	Symbol	Popis
Asociace	──────	"má" vztah
Agregace	──◇──	celek-část, část žije samostatně
Kompozice	──◆──	celek-část, část umírá s celkem
Dědičnost	──▷──	"je" vztah
Realizace	--▷--	implementuje interface
Závislost	──→	"používá"

Sequence Diagram (sekvenční diagram)

Zobrazuje interakce mezi objekty v čase.

Uživatel    UI          Service     Database
   │         │              │           │
   │─login()→│              │           │
   │         │─authenticate()→          │
   │         │              │─findUser()→
   │         │              │←──user────│
   │         │              │─checkPwd()│
   │         │←─token────────│           │
   │←token───│              │           │

Fragmenty: alt (alternativa/if-else), loop (smyčka), opt (volitelné), par (paralelní)

Activity Diagram (diagram aktivit)

Modeluje workflow/business procesy. Podobné vývojovým diagramům, ale s UML notací.

Prvky: Počáteční uzel, akce, rozhodovací uzel (diamond), fork/join (souběžnost), konečný uzel.

State Machine Diagram (stavový diagram)

Pro objekty s komplexním životním cyklem.

[*] → Nová ─────────────→ Zpracování ──→ Odeslaná
              (potvrdit)                      │
                  │                      (doručit)
                  │                           ↓
              Stornovaná ←────────────── Doručená
                          (stornovat)

Přechod: Spouštěcí událost [guard condition] / akce

4. Návrhové vzory (Design Patterns)

Kreační vzory

Singleton — zajistí, že třída má pouze jednu instanci.

class DatabaseConnection:
    _instance = None

    @classmethod
    def get_instance(cls):
        if cls._instance is None:
            cls._instance = cls()
        return cls._instance

    def __init__(self):
        self.connection = self._connect()

Factory Method — vytvoření objektu bez specifikace konkrétní třídy.

class NotificationFactory:
    @staticmethod
    def create(type: str):
        if type == "email":
            return EmailNotification()
        elif type == "sms":
            return SMSNotification()
        raise ValueError(f"Unknown type: {type}")

Strukturální vzory

MVC (Model-View-Controller):

• Model — data a business logika
• View — prezentace (HTML, JSON)
• Controller — zpracování požadavků, orchestrace

Repository Pattern:

class UserRepository:
    def __init__(self, db_session):
        self.session = db_session

    def find_by_id(self, user_id: int) -> User:
        return self.session.query(User).filter_by(id=user_id).first()

    def save(self, user: User) -> User:
        self.session.add(user)
        self.session.commit()
        return user

Behaviorální vzory

Observer Pattern — publish-subscribe mechanismus.

class EventEmitter:
    def __init__(self):
        self._listeners = {}

    def on(self, event: str, callback):
        self._listeners.setdefault(event, []).append(callback)

    def emit(self, event: str, data=None):
        for callback in self._listeners.get(event, []):
            callback(data)

# Použití
emitter = EventEmitter()
emitter.on("user_created", send_welcome_email)
emitter.on("user_created", create_audit_log)
emitter.emit("user_created", {"email": "jan@example.com"})

5. Databázový návrh

Normalizace

1NF (První normální forma):

• Atomické hodnoty v každé buňce
• Žádné opakující se skupiny sloupců

2NF (Druhá normální forma):

• 1NF + žádná částečná závislost na klíči
• Každý neklíčový atribut závisí na celém primárním klíči

3NF (Třetí normální forma):

• 2NF + žádná tranzitivní závislost
• Neklíčový atribut závisí přímo na klíči, ne na jiném neklíčovém atributu

BCNF (Boyce-Codd NF):

• Pro každou FD X → Y: X musí být superklíč

-- Příklad porušení 3NF a náprava
-- ŠPATNĚ: student_id → student_jmeno (tranzitivní přes student)
CREATE TABLE zapis (
    student_id INT,
    predmet_kod VARCHAR(10),
    student_jmeno VARCHAR(100),  -- závisí na student_id, ne na klíči
    znamka INT,
    PRIMARY KEY (student_id, predmet_kod)
);

-- SPRÁVNĚ: rozložení do 3NF
CREATE TABLE studenti (student_id INT PRIMARY KEY, jmeno VARCHAR(100));
CREATE TABLE zapisy (
    student_id INT REFERENCES studenti,
    predmet_kod VARCHAR(10),
    znamka INT,
    PRIMARY KEY (student_id, predmet_kod)
);

Fyzický návrh databáze

Indexy:

-- B-tree index (výchozí) — pro =, <, >, BETWEEN, ORDER BY
CREATE INDEX idx_users_email ON users(email);

-- Složený index — pořadí záleží!
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- Partial index — indexuje jen podmnožinu
CREATE INDEX idx_active_users ON users(email) WHERE is_active = true;

Partitioning — rozdělení velké tabulky pro výkon:

• Range partitioning (datum)
• List partitioning (kategorie)
• Hash partitioning (rovnoměrné rozdělení)

6. REST API návrh

Principy REST

6 omezení REST:

1. Client-Server (oddělení zájmů)
2. Statelessness (server nedrží stav klienta)
3. Cacheability (odpovědi označeny jako kešovatelné/nekešovatelné)
4. Uniform Interface (konzistentní rozhraní)
5. Layered System (klient neví kolik vrstev)
6. Code on Demand (volitelné — JavaScript)

Resource-based URL design:

GET    /users              # seznam uživatelů
POST   /users              # vytvoření uživatele
GET    /users/{id}         # konkrétní uživatel
PUT    /users/{id}         # nahrazení uživatele
PATCH  /users/{id}         # částečná aktualizace
DELETE /users/{id}         # smazání uživatele
GET    /users/{id}/orders  # objednávky uživatele

HTTP Status kódy:

Kód	Popis	Kdy použít
200	OK	Úspěšný GET, PUT, PATCH
201	Created	Úspěšný POST
204	No Content	Úspěšný DELETE
400	Bad Request	Neplatná data
401	Unauthorized	Chybí autentizace
403	Forbidden	Nemá oprávnění
404	Not Found	Zdroj neexistuje
409	Conflict	Duplicitní záznam
422	Unprocessable	Validační chyba
500	Internal Server Error	Chyba serveru

7. Architektonické vzory

Vrstevnatá architektura (Layered)

┌──────────────────────────────┐
│     Presentation Layer       │  API Controllers, Views
├──────────────────────────────┤
│     Application Layer        │  Use Cases, Application Services
├──────────────────────────────┤
│       Domain Layer           │  Entities, Domain Services, Rules
├──────────────────────────────┤
│    Infrastructure Layer      │  DB, External APIs, Email
└──────────────────────────────┘

Clean Architecture / Onion Architecture: Závislosti směřují pouze dovnitř (Domain Layer nezávisí na ničem).

Event-Driven Architecture

Komponenty komunikují prostřednictvím událostí (events).

Výhody: Loose coupling, škálovatelnost, audit trail. Vzory: Event Sourcing (stav = sekvence eventů), CQRS (oddělení čtení a zápisu).

Command → Command Handler → Event → Event Handler(s)
"Vytvoř objednávku" → validace, uložení → OrderCreated → [email, sklad, statistiky]

Mikroservisy vs. Monolit

Kdy mikroservisy:

• Velký tým (Conway's Law)
• Různé škálovací požadavky jednotlivých částí
• Různé technologie
• Potřeba nezávislého nasazení

Kdy monolit:

• Malý tým
• Nejasné hranice domény (modular monolith jako střední cesta)
• Rychlé prototypování

Tipy pro zkoušku

1. Use Case vs. User Story: Use Case = strukturovaná specifikace (základní tok, alternativy, výjimky). User Story = agilní formát "Jako..., chci..., aby..."
2. UML diagramy: Umět nakreslit Class, Sequence, Use Case. Správné vztahy (asociace vs. agregace vs. kompozice vs. dědičnost).
3. Normalizace: Procvičit normalizaci špatného schématu do 3NF — identifikace FD, částečných a tranzitivních závislostí.
4. Design patterns: MVC — rozdělit zodpovědnosti. Repository — abstrakce nad DB. Observer — publish-subscribe.
5. REST: Správné HTTP metody a status kódy. URL struktura (podstatná jména, ne slovesa).
6. Architektura: Kdy monolith vs. mikroservisy. Výhody vrstevnaté architektury.
7. Požadavky: Funkční vs. nefunkční. SMART kritéria pro akceptační kritéria.

Doporučené zdroje

• Arlow, J. & Neustadt, I.: UML 2 and the Unified Process — UML bible
• Fowler, M.: Patterns of Enterprise Application Architecture — návrhové vzory
• Evans, E.: Domain-Driven Design — pokročilá architektura
• Přednáškové materiály katedry informačních technologií FIS VŠE
• Martin Fowler blog: https://martinfowler.com (architektura, refactoring)
• draw.io / Mermaid — nástroje pro UML diagramy