Know-how, előadás, szerződéstervezés, megbízható konstrukció
Absztrakt: Az osztály, az objektum, a paraméterezés alapfogalmai szerint létrehozva olyan szoftver modulokat hozhat létre, amelyek megvalósíthatják az esetleg paraméterezett típusú adatstruktúrákat. Gratulálunk! Fontos lépés volt a legjobb szoftverarchitektúra harcában. De a figyelembe vett módszerek nyilvánvalóan nem elegendők a könyv elején bevezetett átfogó minőségi vízió megvalósításához. A minőségi tényezőket, amelyekre figyelmet fordítottunk - az újrafelhasználásra, a nyújthatóságra, a kompatibilitásra - a megbízhatóság (helyesség és stabilitás) költségén nem lehet elérni. Bár a megbízhatóság fogalmát a vita során megvizsgáltuk, még többet érünk el.
Alapvető megbízhatósági mechanizmusok
Különös figyelmet kell fordítani arra, hogy nagyobb figyelmet kell fordítani az osztályok szemantikai tulajdonságaira, ha felidézzük, hogy egy osztály egy ADT végrehajtása. Az eddig vizsgált osztályok az ATD-specifikáció funkcióit végrehajtó attribútumokat és programokat tartalmazták. De az ATD nem csak a műveletek listája. emlékezzen a szemantikus tulajdonságok szerepére, amelyeket axiómák és előfeltételek fejeznek ki. Ezek az alapok az ilyen típusú példányok jellegének tisztázására. Az osztályokban ideiglenesen elvesztettük az ATD koncepció szemantikai aspektusát. Szükségünk van arra, hogy a szoftverünk ne csak rugalmasan és újrafelhasználható legyen, hanem helyes és stabil is legyen.
Az előadásokban tisztázott kijelentések és kapcsolódó fogalmak részben válaszokat adnak. Mivel nem teljes bizonyíték, az alábbiakban bemutatott mechanizmusok biztosítják a programozó számára a helyességi érvek megfogalmazására és ellenőrzésére szolgáló alapvető eszközöket. A legfontosabb koncepció a Design by Contract - az osztály és az ügyfelek közötti kapcsolatok kialakítása formális megállapodás formájában, amely egyértelműen meghatározza a felek jogait és kötelezettségeit. Csak az egyes modulok követelményeinek és felelősségeinek pontos meghatározása révén reménykedhetünk abban, hogy nagyfokú bizalom érhető el a nagy szoftverrendszerekben.
A koncepciók áttekintése során először találkozunk a szoftverfejlesztés legfontosabb problémájával - hogyan lehet megbirkózni a szerződésszegésből eredő futási idővel. Ez a téma - a kivételes helyzetek kezelése a következő előadás tárgyát képezi. A szerepek elosztása a két fejezet között nagyjából tükrözi a két megbízhatósági összetevő közötti különbséget: helyesség és stabilitás. A helyesség a szoftver képes a feladatoknak a specifikációknak, a fenntarthatóságnak megfelelő feladatok elvégzésére -, hogy képes legyen megfelelően reagálni a specifikáción túlmutató helyzetekre. A kijelentések (ez az előadás) általában szabályozzák a helyességet. kivételek (a következő előadás) a stabilitás.
A fő szerződéstervezési ötletek fontos kiterjesztései az öröklés, a polimorfizmus és a dinamikus kötés bevezetését várják, ami lehetővé teszi számunkra, hogy a szerződésekből alvállalkozásba költözzünk.
A korábbi előadások során bevezetett technikák megbízható szoftver létrehozására irányultak. Tegyünk egy rövid áttekintést - hihetetlenné tennék a fejlettebb fogalmakat, amíg az alapvető megbízhatósági mechanizmusok rendben vannak. Az objektum-technológia első és meghatározó tulajdonsága a szoftververzió szinte megfogalmazott szerkezete - egyszerű, moduláris, bővíthető - könnyebben garantálható a megbízhatóság. mint a korai fejlesztési módszerek alkalmazásából származó struktúrák "görbéi" esetében. Különösen az intermoduláris interakció korlátozására irányuló erőfeszítések, amelyek minimálisra csökkentették, a modularitásról folytatott vita középpontjában álltak. Az eredmény az általános kockázatok tilalma volt. csökkenti a megbízhatóságot. - a globális változók elutasítása, a modulok korlátozott interakciójának mechanizmusa, az örökség és a fészek közötti kapcsolat. Általános megfigyelés: a megbízhatóság (és általában a szoftverek minőségének) legnagyobb ellensége a bonyolultság. A lehető legegyszerűbb struktúrák létrehozásával elérjük a szükséges, de nem elégséges feltételt, amely garantálja a megbízhatóságot. Az előző megbeszélés csak érvényes kiindulópont a következő rendszeres erőfeszítésekben.
Felhívjuk a figyelmet arra, hogy az elegáns és olvasható szoftverek létrehozásának állandó hangsúlyt kell fektetnie, de nem elégséges. A szoftverek szövegei nemcsak írásban vannak, hanem sokszor olvassák és írják újra. A nyelvstruktúrák jelölésének egyértelműsége és egyszerűsége a megbízhatóság bármely kifinomult megközelítésének alapja.
Egy másik szükséges fegyver az automatikus memória kezelés. különös tekintettel a szemétgyűjtésre. Az e témában elhangzott előadásban részletesen elmagyarázzák, miért van olyan dinamikus adatstruktúrát működtető rendszer. annyira veszélyes, hogy manuálisan kezelje ezt a folyamatot. A szemétgyűjtés nem luxus - az OO környezet kulcsfontosságú eleme, amely megbízhatóságot biztosít.
Azt is elmondhatod egy másik mechanizmusról, amelyet a parametrizációval kombinálhatsz, - statikus gépelést. A szigorú statikus gépelés szabályainak hiányában csak a végrehajtási időszak során felmerülő számos hiba engedékenységére kell törekedni.
Mindezek a mechanizmusok biztosítják a szükséges alapot annak teljesebb megítéléséhez, hogy mit kell tenni a szoftver fenntarthatóságának és helyességének biztosítása érdekében.
A szoftver helyességéről
Tegyük fel a kérdést, hogy mit jelent az állítás - a program elem helyes? Az észrevételek és az érvelés, amelyek megválaszolják ezt a kérdést, triviálisnak tűnhetnek. De ahogy egy híres tudós észrevette, ezek mind tudományos eredmények - rendes megfigyelésekkel kezdődnek és egyszerű gondolkodás útján folytatódnak, de mindezt tartósan és kitartóan kell végezni.
Tegyük fel, hogy valaki egy 300 000 soros programot kapott Önhöz és megkérdezte, helyes-e? Ha tanácsadó vagy, akkor magas díjat számol fel, és ne mondja meg. Valószínűleg igazad van.
Annak érdekében, hogy egy ilyen kérdésre ésszerű válasz adható, egy program nem elegendő, a specifikációra is szükség van, ami pontosan leírja, hogy a program mit kell tennie. operátor
önmagában nem helyes vagy helyes. Ezek a fogalmak csak a megbízás várható hatásával kapnak jelentést. Például a hozzárendelés helyes a nyilatkozat szempontjából: "Az x és y változóknak különböző értékeik vannak". De az állítással kapcsolatos helyesség nem garantált: "x változó negatív", mert a hozzárendelés eredménye az y értékétől függ. ami pozitív lehet.
Ezek a példák illusztrálják azt a tulajdonságot, amely kiindulópontként szolgál a helyességi probléma megvitatásában: a szoftverrendszer vagy annak eleme önmagában nem helyes és nem helyes. A helyesség csak bizonyos jellemzőkkel kapcsolatban implicit. Szigorúan szólva, nem fogjuk megvitatni a programelemek helyességének problémáját, csak az adott specifikációval való konzisztenciáját. Megbeszélésünkben továbbra is a "helyesség" jól érthető kifejezést használjuk, de mindig emlékezzünk arra, hogy ez a kifejezés nem alkalmazható a programelemre, csak a párt - "programelem és annak specifikációja" értelme van.
A szoftver helyességi tulajdonsága
A helyesség egy relatív fogalom.
Ebben az előadásban megtudhatjuk, hogyan kell kifejezni az előírásokat állításokkal. amelyek segítenek a kifejlesztett szoftver helyességének értékelésében. De menjünk tovább és fordítsuk át a problémát - a specifikáció fejlesztése az első, legfontosabb lépés az úton, biztosítva, hogy a szoftver valóban megfelel a specifikációnak. Jelentős előnyt érhetünk el, ha a specifikációkat a program írásával párhuzamosan írjuk, és jobb, mielőtt írnánk. Ennek a megközelítésnek a következményei közé tartozik a következő.
- A szoftverfejlesztés a kezdetektől korrekt, helyes. A strukturális programozás egyik alkotója, a Harlan D. Mills a hetvenes években egy olyan cikket írt, amelynek neves címe "Hogyan kell írni a helyes programokat és ismerni". A "tudni" szó ebben az összefüggésben azt jelenti, hogy a programot írás közben az érzelmeket jellemzõ érvekkel látja el.
- A probléma sokkal jobb megértése és megoldásának megvalósítása.
- Egyszerűsítse a szoftverdokumentáció létrehozásának feladatát. Amint később bemutatjuk, a nyilatkozatok fontos szerepet fognak játszani a dokumentáció OO megközelítésében.
- Rendszeres tesztelés és hibakeresés alapjai.
Az előadás további része e kérdések tanulmányozására irányul. Egy figyelmeztetés: a C, C ++ és más programozási nyelvek egy állítással kapcsolatos állítással rendelkeznek. dinamikusan igazolja egy adott nyilatkozat igazságát a program végrehajtása idején és leállítja a számítást. ha a kijelentés hamis. Ez a fogalom, bár a vita témája szempontjából releváns, csak az OO-módszernél alkalmazott állítások kis része. Ezért, ha olyan fejlesztőkhöz hasonlóan, akikkel ismered ezt az üzemeltetőt, ne általánosítsd ismereteidet az egész képre, szinte az összes előadás fogalma új lehet.