Rezumat: Înarmat cu conceptele de bază ale unei clase, obiect, parametrizare, puteți crea acum module software care implementează eventual tipuri parametrizate de structuri de date. Felicitări! Un pas important a fost făcut în lupta pentru cea mai bună arhitectură software. Dar metodele considerate nu sunt suficiente pentru a pune în aplicare viziunea de calitate globală introdusă la începutul cărții. Factorii de calitate pe care ne-am concentrat atenția - reutilizarea, extensibilitatea, compatibilitatea - nu ar trebui realizate cu prețul fiabilității (corectitudine și stabilitate). Deși conceptul de fiabilitate a fost văzut în timpul discuțiilor, realizăm mai mult.
Mecanisme de fiabilitate
Nevoia de a acorda mai multă atenție proprietăților semantice ale clasei devine evidentă în special dacă amintim că o clasă este o implementare a unui ADT. Clasele studiate până în prezent au constat în atribute și programe care implementează funcțiile specificației ATD. Dar ATD nu este doar o listă de operațiuni. amintiți-vă rolul proprietăților semantice, exprimate prin axiome și precondiții. Ele constituie baza pentru clarificarea naturii specimenelor de acest tip. În clase am pierdut temporar acest aspect semantic al conceptului ATD. Este necesar să ne întoarcem astfel încât software-ul nostru să fie nu numai flexibil și reutilizabil, ci și corect și stabil.
Declarațiile și conceptele conexe clarificate în această lecție oferă parțial răspunsuri. Nu este o dovadă completă, mecanismele prezentate mai jos oferă programatorului mijloacele de bază pentru formularea și verificarea argumentelor corectitudinii. Conceptul cheie va fi proiectarea prin contract - stabilirea relațiilor dintre clasă și clienții săi, sub forma unui acord oficial care stabilește în mod neechivoc drepturile și obligațiile părților. Doar prin definirea exactă a cerințelor și responsabilităților pentru fiecare modul putem spera să obținem un grad semnificativ de încredere în sistemele mari de software.
La revizuirea conceptelor, vom întâlni mai întâi problema cheie a ingineriei software - cum să facem față erorilor de execuție generate de încălcarea contractului. Acest subiect - tratarea situațiilor excepționale este subiectul următoarei prelegeri. Distribuția rolurilor între cele două capitole reflectă aproximativ diferența dintre cele două componente ale fiabilității: corectitudinea și stabilitatea. Corectitudinea este capacitatea software-ului de a-și îndeplini sarcinile în conformitate cu specificațiile, durabilitatea - capacitatea de a răspunde în mod corespunzător la situații care depășesc specificațiile. Declarațiile (această prelegere), ca regulă, acoperă corectitudinea. excepții (următoarea prelegere) este stabilitatea.
Unele extinderi importante ale principalelor idei de design contract ar trebui să aștepte introducerea moștenirii, polimorfismului și legării dinamice, ceea ce ne va permite să trecem de la contracte la subcontractare.
Tehnicile introduse în cursurile anterioare au vizat crearea de software fiabil. Să oferim o scurtă trecere în revistă - ar fi inutil să luăm în considerare conceptele mai avansate până când mecanismele fundamentale de fiabilitate sunt puse în ordine. Prima proprietate definitorie a tehnologiei obiectului este structura aproape impusă a sistemului software - simplu, modular, extensibil, - mai ușor de garantat fiabilitatea. decât în cazul "curbelor" structurilor care rezultă din aplicarea metodelor de dezvoltare timpurie. În special, eforturile de limitare a interacțiunii intermodulare, reducând-o la minimum, au fost în centrul discuțiilor privind modularitatea. Rezultatul a fost o interzicere a riscurilor generale. reducerea fiabilității. - respingerea variabilelor globale, mecanismul de interacțiune limitată a modulelor, relația dintre moștenire și cuibărit. Observație generală: cel mai mare dușman al fiabilității (și al calității software-ului în general) este complexitatea. Prin crearea structurilor noastre cât mai simple posibil, atingem condiția necesară, dar nu suficientă, care garantează fiabilitatea. Discuția precedentă este doar un punct de plecare valabil în eforturile sistematice ulterioare.
Rețineți, este necesar, dar și insuficient, un accent constant pe crearea de software elegant și lizibil. Textele software nu sunt doar scrise, ci sunt încă citite și rescrise de mai multe ori. Claritatea și simplitatea notării construcțiilor lingvistice reprezintă baza oricărei abordări sofisticate a fiabilității.
O altă armă necesară este gestionarea automată a memoriei. în special colectarea gunoiului. În prelegerea dedicată acestui subiect, în detaliu se explică de ce pentru orice sistem care gestionează structuri de date dinamice. atât de periculos să se bazeze pe gestionarea manuală a acestui proces. Colecția de gunoi nu este un lux - este o componentă cheie a mediului OO, oferind fiabilitate.
De asemenea, puteți spune despre un alt mecanism, combinat cu parametrizarea, - tastarea statică. Fără regulile de scriere strictă strictă, nu trebuie decât să sperăm să scadă numeroasele erori care apar în timpul perioadei de execuție.
Toate aceste mecanisme oferă baza necesară pentru o viziune mai completă asupra a ceea ce ar trebui făcut pentru a asigura durabilitatea și corectitudinea software-ului.
Cu privire la corectitudinea software-ului
Să punem întrebarea, ceea ce înseamnă declarația - este elementul corect? Observațiile și raționamentul care răspund la această întrebare pot părea triviale. Dar, așa cum a observat un om de știință celebru, acestea sunt toate rezultatele științifice - încep cu observații obișnuite și continuă prin raționament simplu, dar toate acestea trebuie făcute persistent și persistent.
Să presupunem că cineva a venit la tine cu un program de 300.000 de linii în C și a întrebat dacă era corect? Dacă sunteți consultant, încărcați o taxă mare și spuneți nu. Probabil că aveți dreptate.
Pentru a putea da un răspuns rezonabil la o astfel de întrebare, un program nu este suficient, este nevoie și de specificația sa, care descrie cu exactitate ce ar trebui să facă programul. operator
în sine nu este nici corectă, nici corectă. Aceste concepte dobândesc înțeles numai în raport cu efectul așteptat al alocării. De exemplu, atribuirea este corectă în ceea ce privește instrucțiunea: "Variabilele x și y au valori diferite". Dar corectitudinea sa în ceea ce privește declarația nu este garantată: "variabila x este negativă", deoarece rezultatul alocării depinde de valoarea y. care poate fi pozitiv.
Aceste exemple ilustrează o proprietate care servește drept punct de plecare în discutarea problemei corectitudinii: sistemul software sau elementul său nu este nici corect, nici corect în sine. Corectitudinea este implicită numai în legătură cu anumite specificații. Strict vorbind, nu vom discuta problema corectitudinii elementelor programului, ci doar coerența lor cu o specificație dată. În discuțiile noastre, vom continua să folosim termenul bine-înțelept "corectitudine", dar amintim întotdeauna că acest termen nu este aplicabil elementului de program, are sens doar pentru pereche - "elementul de program și specificația sa".
Proprietatea de corectitudine software
Corectitudinea este un concept relativ.
În această prelegere vom învăța cum să exprimăm specificațiile prin afirmații. care va ajuta la evaluarea corectitudinii software-ului dezvoltat. Dar să mergem mai departe și să transformăm problema, - dezvoltarea specificațiilor este primul, cel mai important pas pe cale, asigurându-se că software-ul este cu adevărat conform specificației. Un beneficiu semnificativ poate fi obținut atunci când specificațiile sunt scrise simultan cu scrierea programului și, mai bine, înainte de ao scrie. Printre consecințele acestei abordări se numără următoarele.
- Dezvoltarea software-ului este corectă încă de la început, proiectată să fie corectă. Unul dintre creatorii de programare structurală Harlan D. Mills în anii șaptezeci a scris un articol cu titlul notabil "Cum să scrii programe corecte și să știi asta". Cuvântul "cunoaște" în acest context înseamnă a furniza programul în momentul scrierii sale cu argumente care caracterizează corectitudinea.
- O înțelegere mult mai bună a problemei și realizarea soluției sale.
- Simplificați sarcina de a crea documentația programului. Așa cum se va arăta mai târziu, declarațiile vor juca un rol important în abordarea OO a documentației.
- Furnizarea de bază pentru testarea și depanarea sistematică.
Restul prelegerii este dedicată studierii acestor probleme. Un avertisment: C, C ++ și alte limbi de programare au o afirmație de afirmație assert. verificând dinamic adevărul unei declarații date la momentul executării programului și oprind calculul. dacă declarația este falsă. Acest concept, deși relevant pentru subiectul discuției, este doar o mică parte a utilizării declarațiilor în metoda OO. Prin urmare, dacă mulți dezvoltatori sunteți familiarizați cu acest operator, nu vă generalizați cunoștințele în întreaga imagine, aproape toate conceptele acestei prelegeri pot fi noi.
Articole similare
Trimiteți-le prietenilor: