Návrh na základě smlouvy - Design by contract

Návrh podle smlouvy

Návrh na základě smlouvy (DbC), také známý jako smluvní programování, programování na základě smlouvy a programování podle smlouvy, je přístup pro návrh softwaru.

Předepisuje, že návrháři softwaru by měli definovat formální, přesné a ověřitelné specifikace rozhraní pro softwarové komponenty, které rozšiřují běžnou definici abstraktní datové typy s předpoklady, dodatečné podmínky a invarianty. Tyto specifikace se v souladu s a. Označují jako „smlouvy“ konceptuální metafora s podmínkami a povinnostmi obchodních smluv.

Přístup DbC předpokládá Všechno klientské komponenty které vyvolávají operaci na a komponenta serveru splní předpoklady stanovené pro danou operaci.

Kde je tento předpoklad považován za příliš riskantní (jako u vícekanálového nebo distribuované výpočty ) inverzní přístup je bráno, což znamená, že komponenta serveru testy, které splňují všechny relevantní předpoklady (před nebo během zpracování souboru komponenta klienta 's) a pokud ne, odpoví vhodnou chybovou zprávou.

Dějiny

Termín vytvořil Bertrand Meyer v souvislosti s jeho návrhem Eiffelovský programovací jazyk a poprvé popsáno v různých článcích počínaje rokem 1986[1][2][3] a dvě po sobě jdoucí vydání (1988, 1997) jeho knihy Objektově orientovaná konstrukce softwaru. Společnost Eiffel Software požádala o registraci ochranné známky pro Návrh podle smlouvy v prosinci 2003 a byla udělena v prosinci 2004.[4][5] Současným vlastníkem této ochranné známky je Eiffel Software.[6][7]

Design podle smlouvy má své kořeny v práci formální ověření, formální specifikace a Logika hoare. Původní příspěvky zahrnují:

Popis

Ústřední myšlenkou DbC je metafora o tom, jak prvky softwarového systému vzájemně spolupracují na základě vzájemné závazky a výhody. Metafora pochází z obchodního života, kde se „klient“ a „dodavatel“ dohodnou na „smlouvě“, která například definuje, že:

  • Dodavatel musí poskytnout určitý produkt (povinnost) a je oprávněn očekávat, že klient zaplatil svůj poplatek (výhodu).
  • Klient musí zaplatit poplatek (závazek) a má nárok na získání produktu (výhody).
  • Obě strany musí splňovat určité povinnosti, jako jsou zákony a předpisy, vztahující se na všechny smlouvy.

Podobně, pokud metoda a třída v objektově orientované programování poskytuje určitou funkčnost, může:

  • Očekávejte, že při vstupu bude zaručena určitá podmínka jakýmkoli klientským modulem, který ji volá: metoda předpoklad —Závazek pro klienta a výhoda pro dodavatele (samotná metoda), protože ji osvobozuje od nutnosti vyřizovat případy mimo předpoklad.
  • Zaručit určitou vlastnost na výstupu: metoda podmínka —Povinnost pro dodavatele a zjevně výhoda (hlavní výhoda volání metody) pro klienta.
  • Udržujte určitou vlastnost, předpokládanou při vstupu a zaručenou při výstupu: invariant třídy.

Smlouva je sémanticky ekvivalentní a Hoare triple který formalizuje povinnosti. Lze to shrnout „třemi otázkami“, na které musí návrhář ve smlouvě opakovaně odpovídat:

  • Co smlouva očekává?
  • Co garantuje smlouva?
  • Co smlouva zachovává?

Mnoho programovací jazyky mít vybavení tvrzení jako tyto. DbC však považuje tyto smlouvy za tak zásadní správnost softwaru že by měly být součástí procesu navrhování. Ve skutečnosti se DbC zasazuje napíšu nejprve tvrzení.[Citace je zapotřebí ] Smlouvy mohou být psány komentáře k kódu, vynuceno a testovací sada, nebo obojí, i když pro smlouvy neexistuje žádná speciální jazyková podpora.

Pojem smlouvy sahá až do úrovně metody / postupu; smlouva pro každou metodu bude obvykle obsahovat následující informace:[Citace je zapotřebí ]

  • Přijatelné a nepřijatelné vstupní hodnoty nebo typy a jejich význam
  • Návratové hodnoty nebo typy a jejich významy
  • Chyba a výjimka hodnoty podmínek nebo typy, které se mohou vyskytnout, a jejich význam
  • Vedlejší efekty
  • Předpoklady
  • Postkondice
  • Invarianty
  • (vzácněji) Záruka výkonu, např. pro použitý čas nebo prostor

Podtřídy v an hierarchie dědičnosti mají povoleno oslabit předpoklady (ale neposílit je) a posílit postdokazování a invarianty (ale neoslabit je). Tato pravidla jsou přibližná podtyp chování.

Všechny třídní vztahy jsou mezi klientskými třídami a dodavatelskými třídami. Třída klienta je povinna volat na funkce dodavatele, pokud výsledný stav dodavatele není narušen hovorem klienta. Dodavatel je následně povinen poskytnout návratový stav a údaje, které neporušují státní požadavky klienta.

Například vyrovnávací paměť dat dodavatele může vyžadovat, aby byla data přítomna ve vyrovnávací paměti, když je volána funkce mazání. Dodavatel následně klientovi zaručuje, že když funkce mazání dokončí svou práci, datová položka bude skutečně z vyrovnávací paměti odstraněna. Dalšími konstrukčními smlouvami jsou koncepty invariant třídy. Invariant třídy zaručuje (pro místní třídu), že stav třídy bude na konci každého spuštění funkce udržován v rámci stanovených tolerancí.

Při používání smluv by se dodavatel neměl snažit ověřit, zda jsou podmínky smlouvy splněny - postup známý jako útočné programování - obecná myšlenka spočívá v tom, že kód by měl „selhat tvrdě“, přičemž ověření smlouvy je záchranná síť.

Vlastnost DbC „fail hard“ zjednodušuje ladění chování kontraktu, protože je jasně specifikováno zamýšlené chování každé metody.

Tento přístup se podstatně liší od přístupu obranné programování, kde je dodavatel odpovědný za zjištění, co dělat, když dojde k porušení předběžné podmínky. Více často než ne, dodavatel udělí výjimku, aby informoval klienta, že byla porušena podmínka, a v obou případech - DbC i obranné programování - musí klient přijít na to, jak na to reagovat. V takových případech DbC usnadňuje práci dodavatele.

Design by contract definuje také kritéria správnosti softwarového modulu:

  • Pokud jsou předpoklady třídy invariantní AND před voláním dodavatele klientem, potom invariantní AND podmínka bude po dokončení služby pravdivá.
  • Při volání dodavateli by softwarový modul neměl porušovat předpoklady dodavatele.

Návrh na základě smlouvy může také usnadnit opětovné použití kódu, protože smlouva pro každou část kódu je plně zdokumentována. Smlouvy o modulu lze považovat za formu softwarová dokumentace chování tohoto modulu.

Dopady na výkon

Během provádění bezchybného programu by nikdy nemělo dojít k porušení smluvních podmínek. Smlouvy jsou proto obvykle kontrolovány pouze v režimu ladění během vývoje softwaru. Později při vydání jsou kontroly kontraktů deaktivovány, aby se maximalizoval výkon.

V mnoha programovacích jazycích jsou smlouvy implementovány s tvrdit. Asserts are by default compiled away in release mode in C / C ++, and similarly deactivated in C #[8] a Java.

Spuštění interpretu Pythonu s argumentem „-O“ (pro „optimalizaci“) také způsobí, že generátor kódu Pythonu nevydává žádný bytecode pro tvrzení.[9]

To efektivně eliminuje náklady za běhu deklarací v produkčním kódu - bez ohledu na počet a výpočetní náklady deklarací použitých při vývoji - protože kompilátor žádné takové instrukce do produkce nezahrne.

Vztah k testování softwaru

Návrh na základě smlouvy nenahrazuje běžné strategie testování, jako např testování jednotky, integrační testování a testování systému. Spíše doplňuje externí testování s interními vlastními testy, které lze aktivovat jak pro izolované testy, tak v produkčním kódu během testovací fáze.

Výhodou interních autotestů je, že mohou detekovat chyby, než se projeví jako neplatné výsledky pozorované klientem. To vede k dřívější a konkrétnější detekci chyb.

Použití tvrzení lze považovat za formu testovací věštec, způsob testování návrhu implementací smlouvy.

Jazyková podpora

Jazyky s nativní podporou

Mezi jazyky, které implementují většinu funkcí DbC, patří:

Jazyky s podporou třetích stran

Pro stávající programovací jazyky byly vyvinuty různé knihovny, preprocesory a další nástroje bez nativního designu pomocí podpory smlouvy:

Viz také

Poznámky

  1. ^ Meyer, Bertrand: Návrh podle smlouvy, Technická zpráva TR-EI-12 / CO, Interactive Software Engineering Inc., 1986
  2. ^ Meyer, Bertrand: Návrh podle smlouvy, v Pokroky v objektově orientovaném softwarovém inženýrství, eds. D. Mandrioli a B. Meyer, Prentice Hall, 1991, s. 1–50
  3. ^ Meyer, Bertrand: Použití „návrhu podle smlouvy“, in Computer (IEEE), 25, 10, říjen 1992, str. 40–51, k dispozici také online
  4. ^ „Registrace amerického patentového a známkového úřadu pro„ DESIGN PODLE SMLOUVY"".
  5. ^ „Úřad pro patenty a ochranné známky Spojených států pro grafický design se slovy„ Návrh podle smlouvy"".
  6. ^ „Stav ochranné známky a načítání dokumentů“. tarr.uspto.gov.
  7. ^ „Stav ochranné známky a načítání dokumentů“. tarr.uspto.gov.
  8. ^ „Tvrzení ve spravovaném kódu“. msdn.microsoft.com.
  9. ^ Oficiální dokumenty v Pythonu, tvrdit prohlášení
  10. ^ Bright, Walter (01.11.2014). „Programovací jazyk D, programování smluv“. Digitální Mars. Citováno 2014-11-10.
  11. ^ Hodges, Nicku. „Pište čistší kód vyšší kvality s třídními smlouvami v Delphi Prism“. Embarcadero Technologies. Citováno 20. ledna 2016.
  12. ^ Findler, Felleisen Smlouvy na funkce vyššího řádu
  13. ^ „Scala Standard Library Docs - Assertions“. EPFL. Citováno 2019-05-24.
  14. ^ Silné psaní jako další „vynucování smluv“ ve Scale, viz diskuse na scala-lang.org/.
  15. ^ „Kodexové smlouvy“. msdn.microsoft.com.
  16. ^ "Specifikace ověření fazole". beanvalidation.org.
  17. ^ https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf
  18. ^ „Archivovaná kopie“ (PDF). Archivovány od originál (PDF) dne 2016-03-28. Citováno 2016-03-25.CS1 maint: archivovaná kopie jako titul (odkaz) p. 2
  19. ^ „Žádná šance na vydání pod licencí Apache / Eclipse / MIT / BSD? · Číslo 5 · nhatminhle / cofoja“. GitHub.

Bibliografie

  • Mitchell, Richard a McKim, Jim: Návrh podle smlouvy: příkladem, Addison-Wesley, 2002
  • A wikibook popisující DBC úzce s původním modelem.
  • McNeile, Ashley: Rámec pro sémantiku smluv o chování. Proceedings of the Second International Workshop on Behavior Modeling: Foundation and Applications (BM-FA '10). ACM, New York, NY, USA, 2010. Tato práce pojednává o obecných pojmech Smlouva a Nahraditelnost.

externí odkazy