Objektové paradigma¶

Úvod¶

Objektové paradigma popisuje existující relativitu pohledu na každý prvek systému libovolného typu: buď se popisuje, co prvek nabízí klientům (vnější pohled na služby), anebo jak je nabídka realizována uvnitř (vnitřní pohled na implementaci).

Důležité je, že tyto pohledy mají různý výsledek a pro analytika je tedy u popisu prvku nutné vždy vnímat, o který pohled se jedná — vnější na služby, anebo vnitřní implementující tyto služby. Product Owner jako laik tyto pohledy nerozlišuje a může analytika zavést do slepé uličky.

Pojem Objektové paradigma má v AAF synonyma Object Paradigm, OP (zkratka), objektový princip a objektová filozofie. Všechny formulace jsou rovnocenné. Pojmy vnější pohled a vnitřní pohled mají v AAF synonyma interfacový pohled a implementační pohled.

Objektové paradigma je deskriptivní rámec, nikoli norma nebo doporučení. Platí vždy a pro každý prvek systému. Z toho plyne důležitý důsledek: samotná platnost OP nezaručuje kvalitu řešení. Každý model splňuje OP jako obecně platný jev a přitom může být dobrým nebo špatným řešením daného problému (např. „rozsypaný model objektů" v kódu, zavedení zjevně nesmyslného prvku typu Kočkopes v modelu tříd). OP popisuje strukturu pohledů na prvek, neposuzuje vhodnost prvku samotného.

OP je obecnější princip než postuláty objektově orientovaného programování (OOP). Vlastnosti OOP — zapouzdření, dědičnost, polymorfismus — z OP vyplývají jako důsledky. OP se neomezuje na třídy a objekty programovacího jazyka. Platí pro všechny typy prvků v návrhu IS:

prvek typu Use Case (vnější pohled = užitek pro okolí; vnitřní pohled = scénář implementace)
prvek typu Class (vnější pohled = co prvek umí vydat; vnitřní pohled = atributy a delegace)
prvek typu Function (vnější pohled = volání s parametry; vnitřní pohled = tělo funkce)
prvek typu Component (vnější pohled = poskytovaný interface; vnitřní pohled = implementace komponenty)
prvek typu Tabulka v RDB (vnější pohled = sloupce dostupné přes JOIN; vnitřní pohled = uložení dat)

Tato kapitola popisuje tři jevy, které OP zavádí: vnější pohled na prvek, vnitřní pohled na prvek a nezávislost interakcí mezi prvky.

Vnější pohled na prvek¶

Vnější pohled je popis prvku zvenčí. Klient prvku — jiný prvek, který tento prvek používá — vidí pouze to, co prvek nabízí ven jako svou službu možného použití.

Užitečnou pomůckou je analogie tlačítka. Prvek nabízí ven svá tlačítka služeb. Na každém tlačítku je nápis vystihující službu, kterou klient může použít. Klient stiskne tlačítko a tím tuto službu spotřebuje. Prvek na druhé straně tlačítka odpoví. Klient se nikdy nedívá za tlačítko — neví, co je za ním, jak je služba realizována, jaká vnitřní struktura prvku ji zajišťuje.

Viditelnost interakce končí na hranici prvku. Pokud klient X používá prvek A, je pro X zcela irelevantní, zda A vnitřně používá další prvek C, anebo nepoužívá nic. Z pohledu klienta X je interakce „X používá A" uzavřená na hranici A. Cokoli se odehrává uvnitř A za touto hranicí, je pro X neviditelné.

Z této vlastnosti plyne přesnější formulace, jak větu „X používá Y" číst. Místo „X používá Y" je výstižnější říkat: „Y nabízí ven službu možného použití a X tuto službu zvenku použije." Rozdíl není kosmetický — vyjadřuje, že interakce probíhá přes nabídku služby, nikoli přes znalost vnitřní struktury prvku.

Rozlišující znaky¶

Vnější pohled popisuje prvek z hlediska klienta — co prvek umí vydat, co lze po něm chtít. Vnitřní pohled popisuje prvek z hlediska jeho implementace — jak je nabízená služba uvnitř realizována. Oba pohledy se nesmějí míchat v jedné představě prvku.

Služba je nabídka prvku, kterou klient může použít — analogie tlačítka. Implementace služby je vnitřní mechanismus prvku, který odpověď na použití služby zajišťuje. Klient vidí službu, nevidí implementaci.

Vnitřní pohled na prvek¶

Vnitřní pohled je popis prvku zevnitř — popisuje, jak prvek své nabízené služby realizuje. Implementace služby může být jednoduchá (atribut prvku, krátký výpočet), anebo může delegovat odpověď na další prvky pomocí interakce použití.

Jako příklad uveďme evidovaný prvek typu Class s názvem Student. Vnější pohled říká: „Student umí vydat své rodné číslo." Vnitřní pohled na Studenta může být dvojí:

Student má rodné číslo přímo jako svůj atribut.
Student rodné číslo přímo nemá, ale používá prvek Osoba, který rodné číslo má. Student službu „vydat rodné číslo" implementuje delegací na Osobu.

Oba způsoby implementace dávají z vnějšího pohledu identickou službu. Klient Studenta nepozná, který způsob byl zvolen. Volba mezi nimi je předmětem vnitřního pohledu — analytik se pro jeden z nich rozhodne na základě dalších úvah o struktuře informací v systému (např. unikátnost rodného čísla, sdílení Osoby mezi Studentem a Zaměstnancem).

Anonymita klienta¶

Anonymita klienta je definující vlastnost vnitřního pohledu. Vyplývá přímo z logiky OP: prvek je navržen pro použití, použití znamená opakované použití, opakovaně použít prvek může kdokoli — tedy jakýkoli budoucí klient. Synonymem pro „kdokoli" je anonym. Při návrhu vnitřku prvku je tedy klient nutně anonymní entitou.

Praktický důsledek je striktní: implementace služby se nesmí opřít o předjímání chování klienta. Konkrétně se nesmí předpokládat, kdo službu volá, kdy ji volá, v jakém pořadí ji volá vůči ostatním službám, ani jak se klient zachová mezi voláními. Anonymita klienta proto pokrývá hned několik oblastí návrhu:

Autentikace. Implementace nesmí předpokládat, že klient je tím, za koho se vydává. Identitu klienta je třeba ověřit, ne odhadnout. Příkladem chyby je systém, který knihovníkovi zobrazí jiný seznam než čtenáři podle toho, „kdo asi sedí u stroje" — správné řešení rozlišuje obsah podle role přihlášeného uživatele, ne podle domněnky o uživateli.
Autorizace. Implementace nesmí předpokládat, že klient má právo službu použít. Oprávnění je třeba ověřit při každém volání.
Stavovost. Implementace nesmí předpokládat, v jakém stavu se nachází okolí mezi voláními. Pokud služba potřebuje konzistentní stav, musí si jej zajistit sama (zámkem, transakcí), nikoli spoléhat na to, že klient mezi voláními nezasáhl.
Robustnost vstupů. Implementace nesmí předpokládat, že klient zadá pouze povolené hodnoty. Vstupy je třeba kontrolovat. Pomocné slangové označení této vlastnosti je blbovzdornost prvku — prvek musí relevantně reagovat na jakékoli chování klienta, včetně chybného.
A další oblasti, které vyplynou z konkrétního návrhu — výčet výše není uzavřený.

Anonymní klient je z pohledu prvku „svobodný" — může se zachovat libovolně, včetně způsobů, které autor prvku nepředpokládal. Správná reakce prvku na neočekávané chování klienta je věcná odpověď („tato kombinace vstupů není povolena", „operace v tomto stavu není možná"), nikoli předpoklad, že k ní nikdy nedojde.

Anonymita klienta má důsledky přesahující samotný prvek. Na úrovni Business Process Modelu (BPM) z ní plyne, že nestačí popsat pouze hlavní šťastný průběh procesu (Happy Scenario). Každý proces je nutné zpracovat brainstormingem všech možných větví — co když divák zaplatí pozdě, co když stornuje rezervaci, co když systém v čase mezi voláními ztratil spojení, co když uplyne timeout. Vynechání některé z větví znamená, že se v implementaci anonymního klienta spoléhá na chování, které není pod kontrolou.

Na úrovni Use Case z anonymity klienta plyne požadavek na transakcionalitu. Jedna uživatelská akce, která má proběhnout atomicky, musí být vyřešena jako jedna uživatelská transakce od začátku do konce, se zámkem nad sdílenými prostředky. Není přípustné rozdělit ji na dva nebo více kroků s předpokladem, že se klient mezi nimi „zachová správně" — anonymní klient se mezi nimi může zachovat libovolně.

Rozlišující znaky¶

Anonymita klienta je zachování pravidla, že implementace neví o klientovi nic, co by si nemohla ověřit. Spoléhání na chování klienta je opak — implementace předpokládá, že klient se zachová určitým způsobem, a podle toho se zařídí. Slangově se tato chyba označuje jako „německý ordnung" — návrhář spoléhá, že klient nezadá zakázanou hodnotu, protože „je to v manuálu". Anonymní klient ale manuál nečte; zadá hodnotu, která je technicky možná, a prvek na ni musí relevantně reagovat.

Příklad: Storno rezervace s kontrolou stavu¶

Klient (např. externí systém) chce stornovat rezervaci v systému plateb v případě, že rezervace nebyla zaplacena. Při návrhu této operace se nabízejí dvě varianty.

Varianta A. Klient zavolá „dej stav rezervace", dostane odpověď, a pokud je nezaplaceno, pošle druhý požadavek „stornuj". Tato varianta porušuje anonymitu klienta. Mezi oběma voláními vzniká časová prodleva, ve které může přijít platba — a klient pak stornuje rezervaci, která je už zaplacená. Atomicita kontroly stavu a změny stavu je rozbita.

Varianta B. Klient zavolá Use Case Zpracuj požadavek na storno rezervace. Systém uvnitř Use Case rezervaci nejprve zamkne, zjistí stav, a pokud je nezaplaceno, změní stav na stornováno. Vrací výsledný stav. Kontrola stavu a změna stavu jsou jedna atomická operace pod zámkem.

Nezávislost interakcí¶

Interakce použití mezi prvky má v OP důležitou vlastnost: je směrová. Pokud prvek X používá prvek Y, neplyne z toho, že prvek Y používá prvek X. Pokud je v reálném modelu interakce „tam i zpět", jedná se o dvě nezávislé interakce — jedna ve směru X → Y, druhá ve směru Y → X. Každá z nich má svůj vlastní vnější pohled (na použitý prvek) a svůj vlastní důvod existence.

Z této vlastnosti plyne nezávislost interakcí mezi sebou. Pokud existují interakce „A používá X" a „X používá Y", jsou tyto dvě interakce vůči sobě nezávislé. A „nevidí" interakci „X používá Y", protože tato je vnitřní záležitostí X. Každá interakce končí na hranici použitého prvku.

Vhodnou matematickou analogií je systém ortonormálních souřadnic. Každá interakce je „kolmá" na ostatní — je definována vlastní dvojicí (klient, použitý prvek) a její existence ani povaha nezávisí na ostatních interakcích v systému. Tato vlastnost umožňuje analyzovat, modelovat a měnit interakce nezávisle, jednu po druhé, bez nutnosti řešit celý systém najednou.

Z této nezávislosti plyne důležitý praktický důsledek: problémy v návrhu IS jsou vůči sobě uzavřené a lze je řešit nezávisle, inkrementálně. To je strukturální předpoklad agilní analýzy — pokud by interakce nebyly nezávislé, každá změna jedné interakce by si vynucovala přepracování ostatních, a inkrementální postup by nebyl možný.

Rozlišující znaky¶

Směrová interakce je interakce s pevně daným směrem použití (klient → použitý prvek), kde záměna směru znamená jinou interakci. Symetrický vztah v relační databázi je vztah mezi tabulkami zavedený přes shodu hodnot ve sloupcích (typicky JOIN přes cizí klíč), který je svou povahou symetrický — z technologie RDB nelze rozpoznat, který směr použití byl analyticky zamýšlený. Tato vlastnost RDB může vést k zanedbání směrovosti při analytickém modelování, pokud autor modelu vychází primárně z databázového pohledu. Zanedbání směrovosti je chyba — analytický model musí směr použití vyjadřovat explicitně.

Nejčastější chyby¶

Záměna vnitřního a vnějšího pohledu. Laická formulace „prvek obsahuje informaci X" je z hlediska OP neurčitá — nelze z ní rozeznat, zda je X atributem prvku (vnitřní pohled), anebo zda prvek X umí vydat skrze interakci s jiným prvkem (vnější pohled). Analytik si tuto formulaci v duchu překládá do přesnější verze: „prvek umí vydat informaci X". Tím si ponechává otevřená vrátka pro implementaci službou s delegací.

Záměna platnosti OP za kvalitu řešení. OP platí pro všechny prvky systému vždy. Lze postavit model, který OP splňuje, a přitom je špatným řešením daného problému — například „rozsypaný model objektů" v kódu (prvky bez logické soudržnosti, libovolné vazby) anebo zavedení nesmyslných prvků (slangový Kočkopes — prvek slučující kontradiktorní role pod jednu střechu). OP popisuje strukturu pohledů; nehodnotí, zda byly prvky zvoleny vhodně.

Spoléhání na chování klienta. Slangově „německý ordnung" — autor prvku předpokládá, že klient se zachová způsobem, který autorovi „dává smysl" anebo který je „napsaný v manuálu". Anonymní klient ale nemá žádné povinnosti chování, není z vnitřního pohledu pod kontrolou. Implementace musí relevantně reagovat na všechny technicky možné vstupy, ne pouze na ty „rozumné".

Spoléhání na klienta při generování identifikátorů. Specifický a častý případ chyby Spoléhání na chování klienta. Klient (např. externí systém) si sám generuje identifikátor (ID rezervace, GUID souboru) a posílá jej s požadavkem do prvku, který má požadavek zpracovat. Prvek tak svou klíčovou vlastnost — unikátnost identifikátorů — deleguje mimo svou kontrolu. Pokud klient kvůli chybě v generování posílá duplicitní nebo opakované ID, prvek se zastaví, i když chyba není na jeho straně. Obchodní dopad přitom nese poskytovatel prvku. Správné řešení: identifikátor generuje vždy ten prvek, který službu poskytuje, a vrátí jej jako součást odpovědi na požadavek. Obecněji: pokud klient nemůže garantovat určitou vlastnost, musí si ji prvek garantovat sám. To se týká i dalších autoritativních údajů — časových razítek, stavů, verzí záznamů. Generování identifikátorů (ID rezervace v platebních systémech, GUID souboru v úložišti) patří mezi typické případy, kdy si prvek ponechává kontrolu, i za cenu vyšší pracnosti.

Happy-only scénáře v Business Process Modelu. Autor BPM popíše pouze hlavní úspěšný průběh procesu a vynechá variantní větve (storno, neuhrazeno, timeout, výjimky). Tato chyba je důsledkem ignorování anonymity klienta — autor mlčky předpokládá, že proces vždy proběhne hlavním scénářem. Správný postup je projít všechny možné situace „co se v chodu procesu stane když…" brainstormingem.

Ignorování směrovosti interakce. Autor analytického modelu vyjde z relační databáze a převezme symetričnost JOIN vazeb do analytického modelu. Tím ztratí informaci o směru použití a model přestane být analyticky čitelný. Tato chyba je častá u autorů s primárně databázovým zázemím.

Dvojkroková konstrukce, kde má být jedna transakce. Autor návrhu rozdělí logicky atomickou operaci na dva nebo více kroků s implicitním předpokladem, že se klient mezi nimi zachová „správně" (např. vydá kód a očekává jeho zpětné použití bez zamknutí). Mezi kroky vzniká nezamčená mezera, kterou anonymní klient může využít libovolně. Správné řešení modeluje atomickou operaci jako jednu transakci se zámky a explicitními stavy.

Vazby¶

TBD

Verze a změny¶

Verze	Změny
1.0	První zveřejněná verze kapitoly.