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.

Princip není vázán na software ani na návrh informačních systémů. Platí všude, kde má něco hranici a přes ni nabízí službu.

Přenos do modelování informačních systémů je jeho užším, speciálním použitím. OP je obecnější princip než postuláty objektově orientovaného programování (OOP). Vlastnosti OOP, tedy zapouzdření, dědičnost a 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 pět jevů, které OP zavádí: vnější pohled na prvek, vnitřní pohled na prvek, dva symetrické důsledky hranice (zapouzdření a anonymitu klienta) a nezávislost interakcí mezi prvky.

Vnější pohled na prvek¶

Vnější pohled je popis prvku zvenčí. Klient prvku, tedy 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, tedy co prvek umí vydat, co lze po něm chtít. Vnitřní pohled popisuje prvek z hlediska jeho implementace, tedy 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, tedy 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).

Zapouzdření¶

Zapouzdření je důsledek hranice ve směru zvenku dovnitř: přes hranici prvku není zvenku vidět, jak je služba realizována.

Je to táž vlastnost, kterou popisuje analogie tlačítka, jen pojmenovaná. Klient se za tlačítko nedívá ne proto, že by se to nehodilo, ale proto, že tam nevidí. Vnitřek prvku pro něj neexistuje.

Praktický důsledek je dvojí a oba směry se vyplatí vidět:

Implementaci lze vyměnit, aniž se změní klient. Student může přejít z vlastního atributu na delegaci na Osobu a žádný jeho klient to nepozná. To je vlastnost, kvůli které se vůbec dá model měnit po částech.
Kde vede hranice, rozhoduje analytik. Vytkne-li části implementace jako samostatné prvky, dostanou vlastní hranici a vlastní služby, takže je klient uvidí. Objektové paradigma tím porušeno není, platí i pro ně; model je ale horší a nekonzistentní, protože původní konzistentní pojem jako takový se doslova rozpadl na nekonzistentní prvky.

Zapouzdření platí vždy, protože je to jev, ne pravidlo. Chybovat nelze v něm, ale ve volbě hranic: analytik rozhoduje, co je jeden prvek a co jsou dva. Podle toho pak vypadá, co je uvnitř a co venku.

Krajní podobou je strukturované programování, kde je prvkem i jednotlivá proměnná. Paradigma platí i tam, jen je rozdrobení tak jemné, že model přestává držet pohromadě a vznikají hrubé nekonzistence.

Objektové paradigma tedy říká, že hranice existuje, ale neříká, kudy ji vést. To je otázka, na kterou odpovídají zásady návrhu. Jedna odpovědnost na prvek (SRP) je přímé kritérium pro volbu hranice. Jediný výskyt téhož pravidla (DRY) je naopak důsledek hranice dobře vedené: co je uvnitř jednoho prvku, se jinde neopakuje.

Ukazuje to Student a Zaměstnanec z předchozí sekce. Oba jsou osoby a oba potřebují rodné číslo. Vytkne-li se Osoba jako samostatný prvek a oba na ni delegují, je rodné číslo na jednom místě (DRY) a každý prvek nese jednu odpovědnost (SRP). Rozpustí-li se Osoba do obou, je rodné číslo dvakrát a Student je zároveň studentem i nositelem osobních údajů, tedy Kočkopes z úvodu kapitoly.

Rozlišující znaky¶

Zapouzdření je neprůhlednost hranice ve směru zvenku dovnitř; klient nevidí implementaci. Anonymita klienta je neprůhlednost téže hranice v opačném směru; implementace neví, kdo je klient. Jsou to dva symetrické důsledky jedné hranice, ne dvě jména téhož.

Anonymita klienta¶

Anonymita klienta je důsledek hranice ve směru zevnitř ven a 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.

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 sama nic nepřikazuje, je to popis toho, co prvek o klientovi neví. Přikazuje až to, co z ní plyne: prvek se nesmí spolehnout na nic, co si o klientovi nemůže ověřit. Prohřešit se proti tomu lze čtyřmi cestami.

Cesta 1: nekontrolovaný vstup¶

Implementace se spolehne, že přijde jen to, co je povolené, a nekontroluje, co skutečně přišlo. Sem patří i identita a oprávnění, protože i ta jsou pouhým tvrzením klienta, dokud si je prvek neověří.

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

Slangové označení celé této cesty je „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.

Cesta 2: opomenuté větve mimo šťastný průběh¶

Návrh popíše jen průběh, ve kterém se klient chová, jak se čeká, a spoléhá, že jiné situace nenastanou. Na úrovni Business Process Modelu (BPM) to znamená, ž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, co když klient úvěr nesplácí. Vynechání některé z větví znamená, že se systém spoléhá na chování, které nemá podchycené, a tedy není pod jeho kontrolou.

Cesta 2 je o úplnosti chodu: chod je úplný a konzistentní, když má větev pro každou situaci, která v něm může u klienta nastat, ne jen pro tu očekávanou. Tím se liší od cesty 1, která je o jednom volání, a od cesty 4, která je o nedělitelnosti jedné služby.

Cesta 3: delegace vlastní garance ven¶

Prvek nechá klienta vyrobit údaj, na kterém stojí vlastnost, kterou má garantovat sám. Typickým případem je identifikátor.

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, tedy 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ů, tedy časových razítek, stavů nebo verzí záznamů.

Cesta 4: předčasné vynoření z implementace¶

Prvek rozdělí jednu službu na dvě nebo více a mezi ně vpustí klienta. Část algoritmu, kterým se služba realizuje, se tím vynoří ven z implementace a klient ji má podle metodiky dodržet. Označuje se to jako předčasné vynoření z implementace služby.

Podstatou vady je porušení atomicity, tedy nedělitelnosti realizace. Implementace služby musí v takovém případě proběhnout celá; jakmile se rozdělí na kroky, mezi které se klient dostane, přestává být nedělitelná.

Anonymní klient přitom žádnou metodiku dodržovat nemusí. Spoléhat na to, že projde tlačítka ve správném pořadí a ve správný čas, je totéž spoléhání na německý ordnung jako v cestě 1, jen posunuté do posloupnosti volání.

Implementace tedy nesmí předpokládat, v jakém stavu se nachází okolí mezi svými kroky. Služba proběhne jako jedna nedělitelná operace, tedy všechno nebo nic, s návratem do původního stavu při neúspěchu (rollback). Zámek a transakce jsou k tomu prostředky, ne podstata věci.

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. Prvek nabídne ven dvě tlačítka, Verifikuj stav rezervace a Stornuj. Klient nejprve ověří stav, dostane odpověď „je možné stornovat", a pak stiskne druhé tlačítko. Mezitím ale přišla platba, a klient stornuje rezervaci, která je už zaplacená. Rozhodovací logika se vynořila ven z implementace: prvek nechal klienta, aby ji provedl za něj.

Varianta B. Prvek nabídne ven jedno tlačítko, Use Case Zpracuj požadavek na storno rezervace. Uvnitř proběhne zjištění stavu i jeho změna jako jedna nedělitelná operace, která buď doběhne celá, anebo se vrátí do původního stavu. Klient dostane výsledný stav. Rozhodovací logika zůstala uvnitř, kam patří.

Identitu prvku drží jeho majitel¶

Každý evidovaný prvek má majitele: toho, kdo ho eviduje a odpovídá za něj. Identitu prvku, tedy jeho identifikátor, a stejně tak stav nebo časové razítko, které o prvku vypovídají, vydává a drží majitel. Kdo se na prvek obrací, používá identitu, kterou vydal majitel, a sám ji nevyrábí. Když identitu prvku vydává nebo drží někdo jiný než majitel, je to defekt: majitel nemá pod kontrolou to, za co ručí.

Platí to na obě strany hranice. Prvek nesmí nechat okolí vyrobit identitu vlastního prvku a nesmí sám vyrábět identitu prvku, který patří okolí. Rozhoduje vždy otázka, čí je věc: ten, kdo věc vede, vydává její identitu. Název v textu to neurčuje; laický text může říkat kód rezervace i tomu, co je ve skutečnosti kód platby.

Všechny čtyři cesty jsou povinnosti. Prvek, který se zachová nedefinovaně na neplatném vstupu, neověří oprávnění, nemá větev pro situaci mimo šťastný průběh, nechá jiného než majitele držet identitu prvku, nebo rozdělí nedělitelnou implementaci a vpustí do ní klienta, je vadný. Není co zvažovat.

Příklad: divák objedná v kině lístky. Kino vede rezervaci a vydá k ní svůj kód rezervace. Platební služba vede platbu a vydá k ní svůj kód platby. Když se platba v platební službě identifikuje jen kódem rezervace od kina, drží identitu platby kino, které platbu nevede; to je defekt. Kdyby naopak platební služba vydávala kód rezervace pro rezervaci kina, byl by to defekt na druhé straně. Správně: kino se obrátí na službu, služba vydá kód platby a vrátí ho, kino ho uloží ke své rezervaci a zobrazí divákovi.

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

Výčet cest není uzavřený. Vyjmenované čtyři pokrývají to, co se v praxi vyskytuje nejčastěji; další mohou vyplynout z konkrétního návrhu.

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, jednu ve směru X → Y a druhou 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ý.

Druhý důsledek se týká čtení modelu a jeho zobrazení. Každá interakce je určena vlastní dvojicí klient a použitý prvek a její existence nezávisí na ostatních interakcích. Model se proto dá číst po částech a diagram lze rozdělit na několik menších bez ztráty informace. Co na daném diagramu není, není chybějící údaj; je to buď vnitřek jiného prvku, anebo jiná nezávislá interakce. Úplnost modelu se posuzuje po jednotlivých interakcích, ne podle toho, zda existuje jeden velký obrázek, na kterém je všechno. Tento důsledek se týká obsahu informace, nikoli dopadu změny.

Nezávislost interakcí ale platí jako jev, ne jako záruka. Prakticky ji lze využít jen v modelu, který má čisté prvky. I v modelu, kde jeden prvek nese několik nesouvisejících odpovědností, je formálně každá interakce nezávislá; změna jedné odpovědnosti pak ale zasáhne i klienty, kterým šlo o něco úplně jiného. Předpokladem inkrementálního postupu je proto kvalita modelu a dodržení základních zásad návrhu: hranice vedená podle odpovědností, o které je řeč u zapouzdření, oddělení toho, kdo mění stav, od toho, kdo na změnu reaguje (události, vzor Observer), a dosazení konkrétního prvku zvenku místo pevné vazby uvnitř (Dependency Injection). Výčet není uzavřený, patří sem i další zásady dobrého návrhu. V modelu složeném z prvků typu Kočkopes, které slučují kontradiktorní role, nezávislost interakcí nepomůže; každý zásah se rozlije dál.

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, tedy prvek slučující kontradiktorní role pod jednu střechu). OP popisuje strukturu pohledů; nehodnotí, zda byly prvky zvoleny vhodně.

Chybná představa, že klient vidí dovnitř. Analytik modeluje tak, jako by klient znal vnitřek použitého prvku. Není to porušení zapouzdření, to porušit nelze; je to chybná představa, která posune hranice mezi prvky. Důsledkem je model s roztříštěnými nebo naopak slitými pojmy: vnitřek se popíše i u klienta, takže totéž je na dvou místech (DRY), anebo se odpovědnosti rozdělí a sloučí podle toho, co klient údajně vidí, místo podle toho, co prvek dělá (SRP).

Spoléhání na chování klienta. Cesta 1. 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é".

Happy-only scénáře v Business Process Modelu. Cesta 2. Autor BPM popíše pouze hlavní úspěšný průběh procesu a vynechá variantní větve (storno, neuhrazeno, timeout, výjimky). 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.

Spoléhání na klienta při generování identifikátorů. Cesta 3. Klient si sám generuje identifikátor a prvek na něm staví vlastnost, kterou má garantovat sám. 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.

Předčasné vynoření z implementace. Cesta 4. Autor návrhu rozdělí nedělitelnou operaci na dva nebo více kroků a mezi ně vpustí klienta, 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í). Kus rozhodovací logiky se tím přenese na klienta, který ji dodržovat nemusí. Správné řešení nabídne ven jednu službu a uvnitř ji provede jako nedělitelnou operaci s návratem do původního stavu při neúspěchu.

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.

Vazby¶

Objektové paradigma je jedním ze tří Principů modelování; zbylé dva jsou Zrcadlení pojmů a Předpis a jeho instance. Vnější pohled na systém jako celek popisuje Užitek. Na hranici prvku stojí Zákon zachování informace, který žádá, aby informace, se kterou prvek jedná, měla zdroj; jeho vztah k anonymitě klienta je popsán v jeho kapitole. Nezávislost interakcí je strukturálním předpokladem agilního postupu, viz AAF agilní přístup, Increments Widening.

Verze a změny¶

Verze	Změny
1.5	Sekce Modalita cest není stejná nahrazena sekcí Identitu prvku drží jeho majitel: všechny čtyři cesty jsou povinnosti; u cesty 3 rozhoduje, čí je věc (ten, kdo prvek vede, vydává jeho identitu), na obě strany hranice; název kódu v textu neurčuje, který prvek identifikuje. Dosavadní modalita „cesta 3 je doporučení" byla převzatá z červnového skillu a v bězích cinkání na MTP vedla k tomu, že model porušení viděl, ale hlásil je jen jako doporučení.
1.4	Cesta 2 vymezena jako úplnost chodu (větev pro každou situaci, která může u klienta nastat); vypuštěna formulace „mezi voláními", která sváděla k záměně s cestou 4 (nedělitelnost služby).
1.3	Anonymita klienta má čtyři cesty místo tří: opomenuté větve mimo šťastný průběh vytknuty z cesty 1 do vlastní cesty 2, protože jde o jinou chybu se stejným kořenem (cesta 1 je o tom, co do prvku přijde v jednom volání, cesta 2 o tom, co klient udělá nebo neudělá mezi voláními). Dosavadní cesty 2 a 3 přečíslovány na 3 a 4. Modalita: cesty 1, 2 a 4 jsou povinnosti, cesta 3 doporučení. Nejčastější chyby přečíslovány. Podnětem byla kapitola Agilní postup HLA 2.0, kde se posouzení Use Case Epicu o cesty opírá.
1.2	Do sekce Nezávislost interakcí doplněn druhý praktický důsledek, týkající se čtení modelu a jeho zobrazení: model se dá číst po částech a diagram lze rozdělit na několik menších bez ztráty informace, protože každá interakce je určena vlastní dvojicí klient a použitý prvek. Úplnost modelu se posuzuje po jednotlivých interakcích, ne podle existence jednoho velkého obrázku. Odlišeno od následujícího odstavce: tento důsledek se týká obsahu informace, nikoli dopadu změny.
1.1	Doplněny dvě sekce jako symetrické důsledky hranice: Zapouzdření (dosud v kapitole popsané, ale nepojmenované) a Anonymita klienta povýšená z pod-sekce vnitřního pohledu. Anonymita rozvedena na tři cesty, jak se proti ní prohřešit (nekontrolovaný vstup, delegace vlastní garance ven, předčasné vynoření z implementace) s rozlišením modality: cesty 1 a 3 jsou povinnosti, cesta 2 doporučení porušitelné s důsledky. Doplněna věta, že princip není vázán na software; přenos do modelování IS je jeho užším použitím. Nejčastější chyby přiřazeny k cestám. Doplněn odstavec o tom, že nezávislost interakcí platí jako jev, ne jako záruka, a že inkrementální postup předpokládá kvalitu modelu. Doplněna sekce Vazby, dosud `TBD`. Typ kapitoly změněn z `definice` na `princip` a kapitola zařazena mezi Principy modelování.
1.0	První zveřejněná verze kapitoly.