Špecifická forma a zloženie; EWSTranslate
Správnosť v kompozičných modeloch
Účelom kompozičného návrhu je byť schopný zostaviť systém z komponentov. Všetky výkresy sú do istej miery kompozičné: systémy sú postavené na strojových vyhláseniach, ktoré možno považovať za drobné komponenty. Aby bola kompozícia užitočná, potrebujeme samozrejme niečo viac od kompozičného návrhu. Komponent musí byť súčasťou projektu, tj musí byť výsledkom intelektuálneho úsilia. Až potom je kompozícia užitočná, čo umožňuje dizajnérom zdieľať toto intelektuálne úsilie.
Kompozitné vzory zahŕňajú rôzne typy problémov. Tu nás zaujíma viac problém správnosti: Ako môžeme zo správ špecifikácií jeho komponentov tvrdiť, že je systém správny, alebo inými slovami, čo potrebujeme vedieť o komponentoch, aby sme mohli predpovedať správanie systému? Doklad o zložení nazývame dôkazom správnosti, ak je správnosť systému odvodená zo špecifikácií komponentov. Opäť platí, že každý dôkaz správnosti je v istom zmysle dôkazom zloženia: na preukázanie systému vždy používame určité vedomosti o komponentoch. Rovnako ako predtým pridávame ďalšie obmedzenie: Chceme, aby komponenty obsahovali časť dôkazu o správnosti, pretože by mali obsahovať časť dizajnu. Inými slovami, chceme zostaviť dôkazy o zložení z tvrdení už preukázaných na úrovni zložiek, bez toho, aby sme museli akýkoľvek z týchto dôkazov opakovať. Tento obrázok popisuje špecifikácie a dôkazy v kompozičnom dizajne:
Intuitívne bude množstvo namáhania vzorky vo vzorkách kompozície závisieť od toho, ako sú špecifikované komponenty. Ak je špecifikácia komponentu iba oficiálnym popisom implementácie (tj. Samotným textom programu s dobre definovanou sémantikou), ako je napríklad program UNITY alebo proces CSP, na komponente úrovne sa nevykonáva žiadna časť testovacieho úsilia. a dizajnéri sa musia pri vytváraní dokladu o zložení zaoberať operatívnym a explicitným popisom správania sa komponentov. Špecifikácie komponentov musia byť abstrakciami správania sa komponentov. Musia popisovať užitočné fakty o komponente, fakty, ktoré musia byť preukázané v texte komponentu. Tieto skutočnosti sa potom použijú ako dôkaz o zložení bez povinnosti ich opätovného preukazovania.
Rozdelenie testovacieho úsilia v skutočnosti nevyžaduje kompozičný návrh. Je úplne možné rozdeliť úsilie na zabezpečenie monolitického dôkazu. V tomto prípade je to založené na úplnej špecifikácii systému a operačnom opise celého systému a vyvodzuje sa z toho celkové dôkazné bremeno. Toto dôkazné bremeno sa samo rozkladá a dôkaz správnosti sa zostavuje z dreva a z medzivýsledkov. Tento prístup skúmal napríklad Leslie Lamport so vzorkami TLA +.
Problém takéhoto prístupu spočíva v tom, že špecifikácie nemožno zostaviť veľmi dobre. Je možné, že z vlastností komponentov nemožno logicky odvodiť žiadne (netriviálne) vlastnosti systému. Pre pracovný prístup musia špecifikácie komponentov umožniť návrhárom odvodiť vlastnosti systému. Niektoré špecifikácie komponentov, pretože neobsahujú dostatok informácií, tento odpočet neumožňujú. Problém je v tom, že pretože chceme, aby boli abstraktné, špecifikácie komponentov nemusia obsahovať dostatok informácií. Medzi zachovaním abstraktných špecifikácií a ich premenou na dôkaz kompozície jednoznačne existuje kompromis: stratí sa príliš veľa informácií, príliš veľa podrobností objavených v špecifikáciách a abstrakcia; nestačí to a stratí sa zloženie.
Prípad vždy a vždy
Na ilustráciu rovnováhy medzi abstrakciou a schopnosťou skladať zvážte prípad systémov (a komponentov) definovaných ich nekonečným výpočtom (reaktívne systémy) zložených z paralelného zloženia. Pre tieto systémy sa často používajú dva úzko súvisiace typy vlastností:
- invariant: hovorí sa, že stavový predikát je nemenný, ak:
- drží v počiatočnom stave akýkoľvek výpočet a
- jeho pravda je zachovaná akýmkoľvek vyhlásením systému.
- vždy: hovorí sa, že stavový predikát je „vždy pravdivý“, ak je pravdivý v ktoromkoľvek stave výpočtu systému.
Vo svete časovej logiky sa vlastnosti vždy nazývajú „invarianty“, zatiaľ čo invariantné vlastnosti sa nazývajú „induktívne invarianty“. Na druhej strane, vo svete sekvenčnej kontroly programu sa invariantné vlastnosti nazývajú „invarianty“ a vlastnosti vždy často nemajú názov. (V metóde B sa však nazývajú „vyhlásenia“). To viedlo k určitému zmätku (pozri stránku so substitučnou axiómou).
Prirodzene, vždy a vždy sú spojené: každý predikát, ktorý je nemenný, je tiež vždy pravdivý (indukciou). Predikát však môže byť vždy pravdivý a nemôže byť nemenný. To znamená, že vlastnosti sú vo všeobecnosti vždy slabšie ako invariantné vlastnosti. Sú tiež abstraktnejšie: tvrdia, že predikát je pravdivý v ktoromkoľvek stave výpočtu, ale nehovoria prečo. Premenné vlastnosti hovoria prečo. Inými slovami, invariantné vlastnosti sú užitočným nástrojom na vždy preukázanie vlastností, ale nie sú dostatočne abstraktné na to, aby sa dali použiť na špecifikáciu komponentov.
Z hľadiska zloženia sú vlastnosti nemenné a vždy sa líšia. Pretože programové príkazy sú chránené paralelným zložením, stavový predikát je v systéme invariantný, akonáhle je invariantný vo všetkých komponentoch systému (v našej slovnej zásobe sa invariantné vlastnosti považujú za univerzálne). Pretože konkurenčný systém môže mať prístupnejšie stavy ako jeho komponenty, nie vždy to platí pre vlastnosti: predikát môže byť vždy pravdivý vo všetkých komponentoch systému a falšovaný globálne konkurenčným systémom.
Ak to zhrnieme, invariantné vlastnosti sa dajú zložiť, ale sú príliš silné (nie dosť abstraktné) na to, aby sa dali použiť v špecifikáciách komponentov; vlastnosti sú vždy vlastne nevyhnutnou abstrakciou, ale nedajú sa zložiť. (Užitočnou otázkou je určiť, ktoré vlastnosti sú slabšie ako nemenné vlastnosti, silnejšie ako kedykoľvek predtým a ktoré je možné stále zostaviť.) Táto otázka nie je tak jednoduchá, ako sa zdá, že čitatelia sú vyzvaní, aby sa pokúsili vyriešiť provokatívna otázka súvisiaca s týmto problémom.)
Náš výskum
V našej štúdii sme sa s Mani Chandy zaoberali nasledujúcim problémom: môžeme nájsť vlastnosti komponentov dostatočne silné na to, aby sa dali zložiť, ale dostatočne slabé na to, aby si zachovali abstrakciu? Konkrétne sa zameriavame na dve formy kompozície: existenciálna (existenčná vlastnosť uchovávaná v systéme, akonáhle je v aspoň jednej zložke) a univerzálna (univerzálna vlastnosť uchovávaná v systéme, akonáhle je vo všetkých komponenty). Tieto dve formy zloženia uvažujeme vo všeobecnom kontexte. Komponenty sú abstraktné entity, nie nevyhnutne programy. Nesmie mať atribúty ako „stavy“ alebo „výpočty“. Skladajú sa zo zákona o kompozícii, ktorý by nemal byť paralelným zložením (predovšetkým by nemal byť symetrický alebo idempotentný).
V týchto hypotézach možno preskúmať zaujímavé výsledky (a ešte zaujímavejšie otázky). Tento rámec sa dá použiť na reaktívne systémy a časovú logiku; predovšetkým je možné pekne vyjadriť prípad invariantov, o ktorých sa diskutuje vyššie. Tieto myšlienky možno tiež zovšeobecniť, ak sa používa niekoľko zákonov zloženia súčasne.