---
# System prepended metadata

title: 08 Analýza a návrh systémov

---

# 8. Analýza a návrh systémov

Objektové metody návrhu informačních systémů. Specifikace a řízení požadavků. Softwarové architektury, komponentové systémy. Návrhové a architektonické vzory. Rozhraní komponent, kontrakty na úrovni rozhraní, OCL. Modely softwarových systémů, jazyk UML. Příklady z praxe pro vše výše uvedené. (PA103, PV167, PV258, PV293)

---

## Objektové metódy návrhu informačných systémov

Pri **objektovo-orientovanom návrhu** si zvolíme jednotný jazyk, ktorý pomenúva **triedy** (objekty) a **metódy** nad triedami tak, aby reflektovali koncepty réalneho sveta - danej domény. Zvyčajne ide o podstatné mená (objekty) a slovesá (metódy).
- Výhodou je potom to, že všetci zúčastnení (stakeholderi) od návrhárov až po programátorov **rozumejú** danej doméne
- Jedná sa o **úroveň abstrakcie nad doménou**, ľahko sa podľa nej definujú **komponenty**
- DDD - Domain Driven Development
- Voľba vhodného jazyka na OOP - C#, Java, C++, TypeScript, PHP
- Zvyčajne používame modely **UML** na návrh a analýzu
- Vieme vďaka nej jednoducho **dekomponovať** zložitú architektúru
- Vieme aplikovať **návrhové** a **architektonické vzory**, ktoré jasne popisujú problém a riešenie

## Špecifikácie a riadenie požiadaviek

Požiadavky na systém sa delia na **funkčné** (functional) a **nefunkčné** (non-functional).
- Funkčné - aké funkcie systému zákazník očakáva, jedná sa o biznis logiku (business logic)
- Nefunkčné - aké sú technické nároky na HW a SW, použité technológie, platformy, OS, garancie dostupnosti (SLA), response time, lokalizácia

**Požiadavky riadime** v závislosti na zvolenom projektovom riadení. V **prediktívnom prístupe** sa robí **analýza požiadaviek** so zákazníkom a očakávame, že **všetky požiadavky** na systém budú spísané a budú k nim aj **akceptačné kritéria**. V **agilnom prístupe** sa robí na začiatku iba **obrysová špecifikácia** a v šprintoch sa postupne **dopĺňa backlog** poďla informácií od Product Ownera.
- Typicky používame nástroj na riadenie "**kanban** board" - Jira, Trello, Linear
- V agilnom vývoji sa riadime princípom **MoSCoW** (Must have, Should have, Could have, Wont have)
- Podľa potrieb zákazníka sa prideľuje **priorita**
- Na sprint planningu sa robí **planning poker** na pridelenie **story pointov**
- Po šprinte sa robí **validácia požiadaviek** zákazníkom a následné schválenie

Základom projektového riadenia sú **dobre zadefinované požiadavky**.
- Reflektuje skutočné potreby zákazníka a je v ňom obsiahnuté PREČO to chce
- Má jasné kritérium splnenia, je merateľný a testovateľný
- Má danú prioritu
- Je úplný

V reálnom svete je toto jedna z najťažších vecí softvérového inžinerstva - spoliehame sa, že nám dá zákazník dobre zadefinovanú požiadavku, čo sa neskôr prejaví, že nie je.
- Má za následok **predĺženie projektu** a zvýšenie celkovej ceny, a v konečnom dôsledku **frustruje** vývojárov, menežérov, aj zákazníkov
- Čím neskôr počas behu projektu sa požiadavka zmení, tým drahšie to bude zmeniť

Máme viacero možností ako sa požiadavky dajú zadefinovať:
- **Use Case diagram** - definuje požiadavky ako diagram
- **User story** - Gherkin, bežný text (natural language)
- OCL (Object Constraint Language) - definuje požiadavky nad triedami
- IDL (Interface Definition Language) - definuje požiadavky na API (OpenAPI, Protobuf, WSDL)

Príklad požiadavky Gherkin:
```gherkin
Scenario: Breaker guesses a word
  Given the Maker has chosen a word
  When the Breaker makes a guess
  Then the Maker is asked to score
```

## Softvérové architektúry, komponentové systémy

[6. Distribuované systémy](/vHMHNvzGTLOr2VmF6REVOQ#Rozdiel-medzi-centralizovanou-a-distribuovanou-architektúrou-systému-nevýhody-obidvoch-a-ich-prekonávanie-architektúra-orientovaná-na-služby-SOA)

[7. Programovanie a softvérový vývoj](/fh3I4n2lQCK7jIogm6C8Ag#Viacvrstvová-architektúra-moderných-informačných-systémov-architektura-MVC)

## Návrhové a architektonické vzory

**Vzorom** rozumieme obecné riešenie k často sa opakujúcemu problému, ktorý sa vyskytuje pri návrhu a implementácii softvéru. 
- Umožňujú identifikáciu problémov už počas návrhu systému -> šetrí peniaze
- Ustanovujú terminológiu, ktorá zjednodušuje komunikáciu medzi programátormi a návrhármi systému (napr. "tu dajme Factory", "ten Singleton tu nemá čo robiť")

**Návrhové vzory** (design patterns) riešia objektový návrh a delia sa na:
- **Creational** - riešia vznik objektov (kedy, ako)
    - Singleton - zabezpečuje, že trieda bude mať v behu programu iba jednu inštanciu
    - Factory Method - nahrádzame `new Object` za metódu, ktorá sa dá meniť v subclass
    - Abstract Factory - používame na vytváranie veľa objektov s rôznymi inferfacami (varianty)
    - Prototype - máme metódu `clone()` a rovnaký interface medzi entitami
    - Builder - vytvárame zložité objekty vo viacerých krokoch
- **Structural** - riešia kompozíciu objektov do väčších štruktúr
    - Composite - vytvárame z entít stromové štruktúry nad ktorými celkovo operujeme
    - Adapter - robíme kompatibilný interface k nekompatibilnej triede
    - Bridge - agregácia miesto variant inheritancie (rozdeľuje monolit)
    - Decorator - slúži na nesting funkcionality (rozširuje ju)
    - Proxy - slúži na obalenie funkcionality, náhradu za inú
    - Facade - zaobalujeme komplexitu jednoduchým interfaceom
    - Flyweight - optimalizuje počet nových objektov
- **Behavioral** - riešia algoritmy a definujú závislosti a zodpovednosti medzi objektami
    - Iterator - definuje rôzne spôsoby iterovania nad rôznymi štruktúrami
    - Strategy - definuje nahraditeľné funkcie za behu programu
    - State - extrahuje funkcionalitu do rôznych statových tried
    - Memento - slúži na kopírovanie a obnovenie interného stavu triedy
    - Observer - slúži na vytvorenie zoznamu odoberateľov, ktorým sa zasielajú správy o udalostiach
    - Visitor - slúži na aplikáciu rôznych algoritmov nad dátovými štruktúrami podľa typu

V prípade analýzy domény vieme aplikovať **analytické vzory** (analytical patterns):
- **Accountability**
    - Party - dedenie z objektu, ktorý má závislosti na nejakých ďaľších triedach
    - Organization Hierarchy - trieda, ktorá má cyklickú závislosť a tvorí strom sama zo seba
    - Organization Structure - navyše k hierarchii definuje metadáta a pravidlá závislostí
    - Accountability - to isté ako Organization Structure, len odstránime pravidlá
    - Accountability Knowledge Level - podobné ako Organization Structure s pravidlami
- **Observations and measurements**
    - Quantity - používame ak potrebujeme zapisovať číselné hodnoty s jednotkami
    - Conversion Ratio - k jednotkám pridáme tabuľku konverzií
    - Compound Units - stromová štruktúra jednotiek
    - Measurement - reprezentuje výsledok merania
    - Observation - dokáže zaznamenať nekvantitatívne merania s kategorickou hodnotou

## Rozhranie komponent, kontrakty na úrovni rozhraní, OCL

Na to, aby mohol **komponent** komunikovať so svojím okolím, potrebuje mať zadefinované **rozhranie** (interface). Rozhraniu sa hovorí aj **signatúra**. U rozhrania nás zaujímajú aj **obmedzenia** (constraints) volania (tj. za akého predpokladu sa dá funkcia volať so správnym výsledkom). 
- Signatúra sa skladá z poskytovaných operácií (funkcií, metód) a ich vstupných a výstupných parametrov
- Signatúre a obmedzeniam sa spoločne hovorí **kontrakt** (contract

Súčasťou kontraktu môžu byť:
- **Pre-conditions** - čo musí platiť pred volaním danej metódy, aby prebehla správne
    - Príklad: bankový transfer, pred volaním funkcie Pay máme dostatok peňazí na účte $A - p \geq 0$
- **Post-conditions** - čo musí platiť po skončení volania metódy, prípadne, čo poskytuje
    - Príklad: po skončení funkcie Pay máme na účte $A = A - p$ a na účte $B = B + p$ peňazí
- **Invariants** - čo musí platiť vždy počas volania metódy a ani sa to nezmení po volaní, zvyčajne sa týka premenných triedy
    - Príklad: na debetnom účte nikdy nemôže dojsť k zápornej hodnote

Kontrakty tried **definujeme** pomocou jazyka OCL (Object Constraint Language)
- Je to deklaratívny jazyk (Domain-specific language)
- Vieme používať aj: For, ForAll, Select, Filter, While, Boolean operators, Set operators, Exists, Variables, ...

Príklad:

```
-- Class Transaction
context Transaction
  inv:  amount >= 0

context Transaction::makeTransfer():Boolean 
  pre:  source.getCurrency() = destination.getCurrency()
        and 
	source <> destination
        and amount > 0
 post:  ((source@pre.getBalance() - amount) = (source.getBalance()))
        and 
        ((destination@pre.getBalance() + amount) = destination.getBalance())
 post: source.getBalance() + destination.getBalance()
        = source@pre.getBalance() + destination@pre.getBalance()
```

## Modely softvérových systémov, jazyk UML

**Model softvérového systému** popisuje systém z nejakého zjednodušeného úhla pohľadu.
Rôzne modely sa zaoberajú rôznymi aspektami alebo fázami vývoja systému. Je však dôležité aby tieto modely boli navzájom **konzistentné**.
- Rozdeľujeme na modely popisujúce **štruktúru** a **chovanie**
- Zvyčajne používame modely jazyka UML

**Jazyk UML** je štandardizovaný modelovací jazyk definujúci diagramy, ich vlastnosti a využitie v prostredí vývoja a plánovania. Vieme ho zapisovať aj textovou formou, napríklad pomocou **PlantUML**.

- Structure diagrams (**štrukturálne**)
    - **Class** - zobrazuje štruktúru na úrovni tried, rozhraní, ich funkcií a závislostí
        - Domain Model - analytický diagram, neobsahuje detailné funkcie
        - Implementation Classes - implementačný diagram, obsahuje private/public funkcie a závislosti medzi triedami
    - **Object** - zobrazuje inštancie tried (objekty) a závislosti medzi nimi
    - Package - zobrazuje funkčné celky v balíčkoch, import, use, access
        - **Model** - zobrazuje balíčky a ich nesting, závislosti
    - Composite Structure
        - Internal Structure - používa sa v definícií systémov napr. ako vyzerá HW Routra
        - Collaboration Use - vzťahy medzi aktérmi alebo objektami
    - **Component** - používa sa pri Component-based architecture a Service-based architecture
    - **Deployment** - zobrazuje nasadzované artefakty a systémovú štruktúru
    - Profile - zobrazuje jednoduchú rozšíriteľnosť
- Behaviour diagrams (**behaviorálne**)
    - **Use Case** - definuje akcie (use cases) medzi aktérmi (actors) a subjektami (subjects)
    - **Activity** - zobrazuje tok informácií pri volaní akcií skrz objekty
    - State Machine - definuje vzťahy medzi stavmi
    - Interaction
        - **Sequence** - definuje poradie správ medzi objektami a ich správanie
        - Communication - zobrazuje možnosti komunikácie medzi objektami
        - Timing - zobrazuje časovanie signálov
        - Interaction Overview - kombinuje flow chart s aktivitami

:::warning
ERD nie je súčasťou štandardu UML. Entito-relačné vzťahy sa dajú modelovať pomocou Class diagramu.
:::

### Class Analytical
![Class Analytical](https://hackmd.io/_uploads/HJGdTHjQxl.png)

### Class Implementation
![Class Implementation](https://hackmd.io/_uploads/HyHnpSjQgg.png)

### Object
![Object](https://hackmd.io/_uploads/B16C6Bi7ex.png)

### Model
![Model](https://hackmd.io/_uploads/ryM-Aro7ge.png)

### Component
![Component](https://hackmd.io/_uploads/HyM8CBsmxg.png)

### Deployment
![Deployment](https://hackmd.io/_uploads/HksF0rs7le.png)

### Use Case
![Use Case](https://hackmd.io/_uploads/HyChCHjXee.png)

### Activity
![Activity](https://hackmd.io/_uploads/S1Mzk8jXxe.png)

### Sequence
![Sequence](https://hackmd.io/_uploads/BkaM1Ij7lx.png)

