# 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:

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:  (([e-mail]() - amount) = (source.getBalance()))
        and 
        (([e-mail]() + amount) = destination.getBalance())
 post: source.getBalance() + destination.getBalance()
        = [e-mail]() + [e-mail]()

## 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 Implementation

### Object

### Model

### Component

### Deployment

### Use Case

### Activity

### Sequence