Lo scopo della lezione: acquisire familiarità con i tipi e metodi di controllo e test del software, metodi e strumenti per il debug dei programmi.
Non è sufficiente progettare e codificare un prodotto software; è inoltre necessario assicurarsi che soddisfi i requisiti e le specifiche. Studi condotti più volte hanno dimostrato che quanto prima vengono scoperte alcune incongruenze o errori, tanto più è probabile che vengano corretti e minore è il costo. Le moderne tecnologie di sviluppo software consentono il rilevamento precoce degli errori monitorando i risultati di tutte le fasi e fasi dello sviluppo. Nelle fasi iniziali, il controllo viene eseguito manualmente o utilizzando ASTUCCIO- fondi, su quest'ultimo - assume la forma di test.
Test è il processo di esecuzione di un programma il cui scopo è rilevare gli errori. Nessuna quantità di test può dimostrare l'assenza di bug nel software complesso, poiché diventa impossibile eseguire test completi e c'è la possibilità che ci siano bug non scoperti. Il rispetto delle regole di base dei test e la selezione scientifica dei test possono ridurne il numero. Il processo di sviluppo secondo il moderno modello del ciclo di vita del software prevede tre fasi di test: autonomo test di componenti software; complesso test di software sviluppato; sistemico o valutativo verifica del rispetto dei principali criteri di qualità. Per migliorare la qualità dei test, si consiglia di attenersi ai seguenti principi di base:
i risultati attesi devono essere conosciuti prima del test;
si dovrebbe evitare di testare il programma da parte dell'autore;
è necessario studiare a fondo i risultati di ogni test;
è necessario controllare le azioni del programma su dati errati;
è necessario controllare il programma per effetti collaterali imprevisti su dati errati.
La probabilità di bug non rilevati in una parte di un programma è proporzionale al numero di bug già trovati in quella parte. Riuscito considera un test che rilevi almeno un errore. La formazione di una serie di test è di grande importanza, poiché il test è una delle fasi più dispendiose in termini di tempo nello sviluppo del software. La quota del costo del test nel costo totale dello sviluppo aumenta con l'aumentare della complessità del software e dei requisiti più elevati per la loro qualità.
Esistono due approcci fondamentalmente diversi alla formazione di suite di test: strutturale e funzionale. Approccio strutturale basato sulla struttura nota software testato, inclusi i suoi algoritmi (" scatola di vetro"). I test sono costruiti per verificare la correttezza dell'implementazione della logica data nel codice del programma. Funzionaleun approccio si basa sul fatto che la struttura del software non è nota (" scatola nera"). In questo caso, i test vengono costruiti sulla base di specifiche funzionali. Questo approccio è anche chiamato un approccio basato sui dati poiché quando lo si utilizza, i test sono costruiti sulla base di vari metodi di decomposizione di un insieme di dati. Le suite di test derivate da questi approcci vengono combinate per fornire test completi del software.
Controllo manuale utilizzato nelle prime fasi di sviluppo. Tutte le decisioni progettuali vengono analizzate quanto prima in termini di correttezza e adeguatezza, mentre possono essere facilmente riviste. Distinguere statico e dinamico approcci al controllo manuale. Con statica approccio, la struttura, il controllo e le connessioni informative del programma, i suoi dati di input e output vengono analizzati. quando dinamico- eseguire test manuale(simula manualmente il processo di esecuzione del programma sui dati iniziali forniti). I dati iniziali per tali controlli sono: specifiche tecniche, specifiche, diagrammi strutturali e funzionali di un prodotto software, diagrammi dei singoli componenti e per le fasi successive - algoritmi e testi di programma, nonché suite di test. È stato dimostrato che il controllo manuale contribuisce a un aumento significativo della produttività e dell'affidabilità dei programmi e può aiutare a trovare dal 30 al 70% degli errori di progettazione logica e di codifica. I principali metodi di controllo manuale sono: ispezioni del codice sorgente, viste end-to-end, controllare al tavolo, valutazioni del programma.
Al centro della prove strutturali risiede il concetto del test più completo di tutti itinerarifornito dall'algoritmo (una sequenza di istruzioni del programma eseguite con una versione specifica dei dati iniziali). Svantaggi: le suite di test costruite non rilevano percorsi mancanti ed errori che dipendono dai dati incorporati; non garantiscono che il programma sia corretto.
Un altro modo per controllare i programmi è funzionale test: il programma è visto come " scatola nera", Lo scopo del test è scoprire quando il comportamento del programma non è conforme alle specifiche. Per trovare tutti gli errori, devi eseguire esaurientetest (con tutti i set di dati possibili), che è impossibile nella maggior parte dei casi. Pertanto, di solito eseguono " ragionevole" o " accettabile»Test limitato all'esecuzione del programma su un piccolo sottoinsieme di tutti i possibili input. Nei test funzionali, si distinguono i seguenti metodi di formazione dei casi di test: partizione equivalente; analisi del valore limite; analisi causale; ipotesi di errore.
quando un integrato test utilizzare test basati su metodi di classi equivalenti, condizioni al contorno e ipotesi di errore, poiché i test strutturali non sono applicabili. Uno dei più difficili è la questione del completamento del test, poiché è impossibile garantire che non siano rimasti errori nel programma. Il test viene spesso interrotto perché il tempo assegnato per la sua esecuzione è scaduto. È piegato, spostandosi test minimi , che presuppone: verifica dei valori limite, verifica approfondita del manuale, verifica della configurazione minima dell'hardware, capacità di modificare i comandi e ripeterli in qualsiasi sequenza, resistenza agli errori dell'utente.
Dopo aver completato il test completo, passare a valutativo test, il cui scopo è trovare incongruenze con i termini di riferimento. I test di valutazione includono test: usabilità, limite di volume, limite di carico, usabilità, sicurezza, prestazioni, requisiti di memoria, configurazione hardware, compatibilità, facilità di installazione, manutenzione, affidabilità, ripristino, documentazione, procedura.
Debug è un processo localizzazione (determinazione dell'operatore del programma, la cui esecuzione ha causato una violazione del processo di calcolo) e correzione degli errori riscontrati durante il test del software. Per correggere l'errore, è necessario determinarne la causa. Il debugging richiede che un programmatore abbia una profonda conoscenza delle specifiche di gestione dell'hardware utilizzato, del sistema operativo, dell'ambiente e del linguaggio di programmazione, dei processi da implementare, della natura e delle specifiche degli errori, delle tecniche di debugging e del software corrispondente; psicologicamente scomodo (è necessario cercare i propri errori in un tempo limitato); lascia la possibilità di influenza reciproca di errori in diverse parti del programma. Non esistono tecniche di debug ben definite. Distinguere:
errori di sintassi- accompagnato da un commento che ne indica la posizione, fissato dal compilatore (traduttore) durante l'esecuzione di analisi sintattiche e parzialmente semantiche;
errori di layout- trovato dal linker (linker) durante l'unione dei moduli del programma;
errori di runtime -rilevato dall'hardware, dal sistema operativo o dall'utente durante l'esecuzione del programma, manifest diversi modi ea loro volta sono divisi in gruppi:
errori di definizione dei dati di origine (errori di trasmissione, errori di conversione, errori di riscrittura ed errori di dati);
errori di progettazione logica (metodo inapplicabile, algoritmo errato, struttura dati errata, ecc.) ed errori di codifica (errori utilizzando le variabili, calcoli, interfaccia tra moduli, implementazione di algoritmi, altro);
errori nell'accumulo di errori nei risultati del calcolo (ignorando i limiti della griglia di bit e le modalità per ridurre l'errore).
Il debugging di un programma presuppone in ogni caso il pensiero e la comprensione logica di tutte le informazioni disponibili sull'errore. La maggior parte degli errori può essere rilevata da segni indiretti attraverso un'analisi approfondita dei testi del programma e dei risultati dei test senza ottenere ulteriori informazioni utilizzando i seguenti metodi:
test manuale (se viene rilevato un errore, è necessario eseguire manualmente il programma in prova utilizzando il set di test, durante il quale è stato rilevato l'errore);
induzione(basato su un'analisi approfondita dei sintomi di errore, che possono apparire come risultati di calcolo errati o come messaggio di errore);
deduzione (in primo luogo, formano un insieme di ragioni che potrebbero causare questa manifestazione di un errore e quindi, analizzando le ragioni, escludono quelle che contraddicono i dati disponibili);
tornare indietro (per il punto di inferenza di un risultato errato, si costruisce un'ipotesi sui valori delle principali variabili che potrebbero portare alla ricezione di questo risultato, e poi, in base a questa ipotesi, si fanno ipotesi sui valori delle variabili al punto precedente).
Per ulteriori informazioni sull'errore, vengono eseguiti test aggiuntivi e vengono utilizzati metodi e mezzi speciali: output di debug; strumenti di debug integrati; debugger indipendenti.
Metodologia generale per il debug di prodotti software scritti per l'esecuzione nei sistemi operativi MS DOS e Win32:
Fase 1- studio della manifestazione dell'errore;
Fase 2 -determinazione della localizzazione degli errori;
Fase 3- determinazione della causa dell'errore;
Fase 4 -risoluzione del problema;
Fase 5 -ripetere il test.
Il processo di debug può essere notevolmente semplificato se si seguono le raccomandazioni di base dell'approccio strutturato alla programmazione:
costruire il programma "top-down", dall'interfaccia alle subroutine di elaborazione, testandolo mentre si aggiungono subroutine;
visualizzare all'utente i dati da lui inseriti per il controllo e verificarne l'ammissibilità immediatamente dopo l'inserimento;
prevedere l'output dei dati di base in tutti i punti nodali dell'algoritmo (rami, chiamate di subroutine).
Ulteriori informazioni sull'argomento possono essere ottenute all'indirizzo.
Obbiettivo:
Testare ed eseguire il debug di un programma specifico sviluppato in precedenza su linguaggio algoritmico alto livello.
Ordine di lavoro e reportistica.
Durante il lavoro di laboratorio, è necessario comporre una serie di test per il programma sviluppato in precedenza ed eseguirne il debug.
La serie di test compilata dovrebbe essere presentata nel rapporto.
Informazioni teoriche.
Il test è il processo di esecuzione di un programma per determinare il luogo del suo funzionamento errato. Implica la progettazione deliberata di insiemi di dati di input difficili che creano il maggior potenziale di guasto del prodotto software. Il test è il metodo principale per rilevare gli errori in un programma. I risultati del test sono i dati iniziali per il debug.
Il debug di un programma è la fase del suo sviluppo, che elimina le carenze del programma appena creato.
Se un programma si comporta correttamente per un solido insieme di test, non c'è motivo di affermare che non abbia bug. Semplicemente non si sa quando non funziona e si può parlare solo di un certo livello di correttezza.
I test che non aiutano a rilevare errori e confermano solo il corretto funzionamento del programma sono inefficaci, perché portare a uno spreco di risorse e tempo.
Un test è un esempio calcolato manualmente o in altro modo, i cui risultati intermedi e finali vengono utilizzati per controllare la correttezza (sopravvivenza) di un prodotto software. Il test consiste nei dati iniziali e in quei valori che dovrebbero essere stampati dalle stampe di debug quando si lavora su questo test. Questi valori devono essere registrati esattamente nella forma in cui il computer dovrebbe fornirli. È desiderabile ottenere questi valori in qualsiasi modo, ma non quello implementato nel programma, da allora in quest'ultimo caso potrebbero non essere rilevati errori di algoritmo.
La suite di test dovrebbe essere così:
Per controllare tutte le opzioni per l'effetto esterno del programma e le opzioni per il suo lavoro interno dell'algoritmo;
In modo che tutti i rami dell'algoritmo vengano attraversati almeno una volta.
Per controllare casi limitanti e degenerati.
I dati del test devono essere selezionati in modo tale che il programmatore sia in grado di calcolare il risultato corretto anche prima dell'inizio del test.
Il processo di test del programma può essere suddiviso in tre fasi:
1. Controllo in condizioni normali.
2. Controllo in condizioni estreme.
3. Controllare in situazioni eccezionali.
Ciascuna di queste tre fasi di convalida deve garantire che si ottengano risultati corretti con input corretti e che vengano segnalati messaggi di errore per input errati.
Controllo in condizioni normali
I casi in cui un programma deve funzionare con tutti i dati di input possibili sono estremamente rari. Di solito, ci sono restrizioni specifiche sull'area di modifica dei dati in cui il programma deve mantenere le sue prestazioni. Il programma deve produrre risultati corretti per set rappresentativi di dati di input.
Controllo in condizioni estreme
I dati di test di questa fase includono i valori limite dell'intervallo delle variabili di input, che dovrebbero essere percepiti dal programma come dati validi. Esempi tipici sono numeri molto grandi, numeri molto piccoli o nessuna informazione.
Controllo in situazioni eccezionali.
Vengono utilizzati i dati di origine, i cui valori si trovano al di fuori dell'intervallo consentito per la loro modifica. La situazione peggiore è quando il programma percepisce i dati errati come corretti e produce un risultato errato ma plausibile. Il programma deve rifiutare tutti i dati che non può gestire correttamente.
Test di esempio.
Lascia che sia necessario calcolare la lunghezza della diagonale di un parallelepipedo usando la formula È necessario generare dati di prova per condizioni normali, estreme ed eccezionali.
|
Parti Parallelepipedo |
Nota |
|||
Buon test normale d 1.7320508 |
||||
I concetti di "debugging", "program debugging". Processo di debug. Tipi (tecnica) di debugging, metodi di debugging.
Dopo che il processo di progettazione del modulo è stato completato e il codice del programma è stato scritto, è necessario compilare il programma. Durante il processo di compilazione, è necessario correggere non solo gli errori, ma anche le osservazioni. La maggior parte degli errori sono di natura sintattica. Spesso, i messaggi su un tale errore vengono visualizzati nella fase di scrittura del codice del programma. Se l'errore non viene corretto dall'utente, il testo dell'operatore verrà evidenziato in rosso. Se gli errori di compilazione vengono corretti, quando si esegue l'applicazione non è affatto necessario che non si verifichino nuovi errori. Questi possono essere errori logici. Con alcuni dati possono comparire degli errori: divisione per 0, overflow, estrazione della radice quadrata di un numero negativo, mancata inizializzazione all'inizio dei calcoli, apertura di un file inesistente, ecc.
Quando si verifica un'eccezione in fase di esecuzione, il compilatore informa l'utente in una finestra di dialogo.
Quando l'applicazione viene interrotta, la riga verrà evidenziata in giallo se la finestra di dialogo viene chiusa facendo clic sul pulsante Debug. Se il messaggio di errore è stato chiuso con il pulsante Fine, verrà contrassegnato il titolo della procedura in cui è stato riscontrato l'errore.
Debug di un programma
Il debug, come abbiamo detto, è di due tipi:
· Debug sintattico... Gli errori di sintassi vengono rilevati dal compilatore, quindi è facile risolverli.
· Debug semantico (semantico)... Il suo momento arriva quando errori di sintassi non a sinistra, ma il programma produce risultati errati. Qui, il compilatore stesso non sarà in grado di rivelare nulla, anche se nell'ambiente di programmazione di solito ci sono aiuti per il debug, di cui parleremo più avanti.
Debug è il processo di localizzazione e correzione degli errori nel programma.
Principi di debug
Principi di localizzazione degli errori:
· La maggior parte degli errori vengono rilevati senza avviare affatto il programma, semplicemente esaminando attentamente il testo.
· Se il debug è in deadlock e l'errore non può essere rilevato, è meglio posticipare il programma. Quando l'occhio è "sfocato", l'efficienza lavorativa tende ostinatamente a zero.
· Mezzi ausiliari estremamente convenienti sono i meccanismi di debug dell'ambiente di sviluppo: tracciamento, controllo intermedio dei valori. È anche possibile utilizzare un dump della memoria, ma raramente sono necessarie azioni così drastiche.
· Esperimenti come "cosa succederà se si cambia il più in meno" - dovrebbero essere evitati con tutti i mezzi. Di solito questo non dà risultati, ma confonde solo di più il processo di debug e aggiunge anche nuovi errori.
I principi di correzione degli errori sono ancora più simili alle leggi di Murphy:
· Se viene rilevato un errore, potrebbero essercene altri.
· La probabilità che l'errore venga rilevato correttamente non è mai del cento percento.
· Il nostro compito è trovare l'errore stesso, non il suo sintomo.
Vorrei chiarire questa affermazione. Se il programma fornisce ostinatamente il risultato 0.1 invece dello zero di riferimento, l'arrotondamento semplice non risolverà il problema. Se il risultato è negativo invece del riferimento positivo, è inutile prenderlo modulo - invece di risolvere il problema, otterremo una sciocchezza con l'adattamento.
· Correggendo un errore, è molto facile aggiungerne altri due al programma. I bug agganciati sono la vera piaga del debugging.
· La correzione degli errori spesso ci costringe a tornare alla fase di programmazione. Questo è spiacevole, ma a volte inevitabile.
Metodi di debug.
1 metodi efficaci
o Utilizzo di un dump della memoria (stampa).
Questo è interessante da un punto di vista cognitivo: puoi comprendere a fondo i processi della macchina. A volte questo approccio è persino necessario, ad esempio quando si tratta di allocare e liberare memoria per variabili dinamiche utilizzando caratteristiche del linguaggio non documentate. Tuttavia, nella maggior parte dei casi, otteniamo un'enorme quantità di informazioni di basso livello, che il nemico non vorrà trattare e le prestazioni di ricerca sono incredibilmente basse.
o Utilizzo della stampa di debug nel testo del programma - arbitrariamente e in grandi quantità.
Anche ottenere informazioni sull'esecuzione di ogni istruzione è interessante. Ma anche qui ci troviamo di fronte a troppe informazioni. Inoltre, riempiamo praticamente il programma con operatori aggiuntivi, ottenendo testo illeggibile e rischiamo persino di introdurre una dozzina di nuovi errori.
o Utilizzo di strumenti di debug automatico - tracciamento con tracciamento dei valori intermedi delle variabili.
Questo è probabilmente il metodo di debug più comune. Non si dovrebbe solo dimenticare che questo è solo uno dei modi, e spesso non è redditizio applicarlo sempre e ovunque.
Le difficoltà sorgono quando è necessario tenere traccia di strutture di dati troppo grandi o di un numero enorme di esse. Ancora più problematico è tracciare il progetto, dove l'esecuzione di ogni subroutine porta alla chiamata di un paio di dozzine di altre. Ma per piccoli programmi, la traccia è sufficiente.
Dal punto di vista della programmazione "corretta", i metodi di forzatura sono pessimi in quanto non incoraggiano l'analisi del problema.
Riassumendo le proprietà dei metodi di alimentazione, otteniamo consigli pratici:
o utilizzare la tracciatura e la tracciabilità dei valori delle variabili per piccoli progetti, routine separate;
o utilizzare la stampa di debug in piccole quantità e "per lavoro";
o lasciare un dump della memoria come ultima risorsa.
2. Metodo di induzione - analisi del programma dal particolare al generale.
Esaminiamo i sintomi dell'errore e determiniamo i dati che hanno almeno qualche relazione con esso. Quindi, utilizzando i test, eliminiamo le ipotesi improbabili finché non ne rimane una, che stiamo cercando di perfezionare e dimostrare.
3. Il metodo di deduzione - dal generale al particolare.
Abbiamo avanzato un'ipotesi che può spiegare l'errore, anche se non completamente. Quindi, utilizzando i test, questa ipotesi viene testata e dimostrata.
4. Movimento inverso secondo l'algoritmo.
Il debug inizia dove si incontra per la prima volta il risultato sbagliato. Quindi il lavoro del programma viene tracciato (mentalmente o con l'aiuto di test) in ordine inverso fino a trovare il luogo di un possibile errore.
5. Metodo di prova.
· Metodo di induzione.
L'induzione è un'analisi dal particolare al tutto. Osservando i sintomi di errore identificati da uno o più test e le relazioni tra di essi, è possibile individuare la causa dell'errore.
· Metodo di detrazione.
Questo metodo consente, sulla base di alcuni teorie generali o prerequisiti, utilizzando gli operatori di eccezione o di raffinamento, per giungere a una certa conclusione (per trovare il luogo dell'errore). Per trarre una conclusione, dobbiamo esaminare tutte le informazioni a nostra disposizione: tutti i risultati di tutti i test su tutti gli errori. Le ipotesi avanzate sono una ad una escluse dalla considerazione.
· Tracciare la logica al contrario.
Metodo di localizzazione per piccoli errori. Il debug inizia nel punto del programma in cui si incontra un risultato. A questo punto, in base al risultato ottenuto, è necessario stabilire quali dovrebbero essere i valori delle variabili. Eseguendo mentalmente da un dato punto del programma in ordine inverso e ragionando di nuovo in questo modo: "Se lo stato del programma fosse così a questo punto, lo stato successivo dovrebbe essere in un altro punto", puoi localizzare rapidamente e accuratamente l'errore, ad es. trovare un posto nel programma tra il punto in cui lo stato del programma corrispondeva a quello atteso e il punto in cui lo stato del programma era diverso da quello atteso.
Strumenti automatizzati per il debug dei programmi.
Funzionalità del debugger standard. Controllo della correttezza del programma scritto (fasi).
Strumenti di debug
Oltre alle tecniche, è bene avere una comprensione degli strumenti che ci aiutano a identificare gli errori. Esso:
1) Stampa di emergenza: visualizza messaggi sul completamento anomalo di singoli blocchi e dell'intero programma nel suo insieme.
2) Stampa nei nodi del programma - output dei valori intermedi dei parametri nei posti selezionati dal programmatore. Di solito, queste sono parti critiche dell'algoritmo (ad esempio, il valore da cui dipende l'ulteriore progresso dell'esecuzione) o le componenti di formule complesse (calcola e visualizza separatamente il numeratore e il denominatore di una grande frazione).
3) Tracciamento diretto:
Aritmetica (dopo quanto sono uguali, quando e come cambiano le variabili selezionate),
Logico (quando e come viene eseguita la sequenza di istruzioni selezionata),
Controllo degli indici che superano i limiti consentiti,
Monitoraggio dell'accesso alle variabili,
Monitoraggio delle chiamate alle subroutine,
· Controllo dei valori degli indici degli elementi dell'array, ecc.
Gli ambienti di sviluppo odierni spesso ci chiedono di reagire a un problema emergente in modalità interattiva. In questo caso puoi:
· Visualizzare i valori correnti delle variabili, lo stato della memoria, la sezione dell'algoritmo in cui si è verificato l'errore;
· Interrompere l'esecuzione del programma;
· Apportare modifiche al programma e rieseguirlo (negli ambienti del compilatore, ciò richiederà la ricompilazione del codice; negli ambienti interpretati, è possibile continuare l'esecuzione direttamente dall'istruzione modificata).
Si consiglia di eseguire il test autonomo di un modulo in quattro fasi sequenziali.
Passo 1. In base alle specifiche del modulo da sottoporre a debug, preparare i test per ciascuna opportunità e situazione, per ogni limite dell'intervallo valido di tutti gli input, per ogni intervallo di modifiche dei dati, per ogni intervallo non valido di tutti gli ingressi e ogni condizione non valida.
Passo 2. Controllare il testo del modulo per assicurarsi che ogni direzione di qualsiasi ramo supererà almeno un test. Aggiungi test mancanti.
Passaggio 3. Controllare il testo del modulo per assicurarsi che ci siano test per ogni ciclo che forniscano almeno le seguenti tre situazioni: il corpo del ciclo non viene mai eseguito, il corpo del ciclo viene eseguito una volta e il corpo del ciclo viene eseguito il maggior numero di volte possibile. Aggiungi test mancanti.
Passaggio 4. Controllare il testo del modulo per assicurarsi che siano presenti test che testano la sensibilità a particolari valori speciali nell'input. Aggiungi test mancanti.
Suggerimenti per il debugger
1) Controlla più attentamente: l'errore è molto probabilmente nel posto sbagliato dove sembra.
2) Spesso risulta più facile evidenziare quelle parti del programma, in cui non ci sono errori, e poi guardare nel resto.
3) Seguire attentamente le dichiarazioni di costanti, tipi e variabili, dati di input.
4) Nello sviluppo sequenziale, devi essere particolarmente attento quando scrivi driver e stub: essi stessi possono essere fonte di errori.
5) Analizza il codice partendo dal più opzioni semplici... Gli errori più comuni sono:
I valori degli argomenti di input vengono accettati nell'ordine sbagliato,
La variabile non è inizializzata,
Quando si ripassa il modulo, la variabile non viene reinizializzata,
Invece di copiare presumibilmente l'intera struttura dei dati, solo livello superiore (ad esempio, invece di creare una nuova variabile dinamica e assegnarle il valore desiderato, l'indirizzo viene stupidamente copiato da una variabile già esistente),
· Le parentesi in un'espressione complessa sono inserite in modo errato.
6) Con il debug persistente a lungo termine, gli occhi "sfocano". È buona norma chiedere aiuto a un'altra persona per non ripetere ragionamenti errati. Tuttavia, spesso rimane una sfida convincere l'altra persona ad aiutarti.
7) L'errore molto probabilmente sarà tuo e sarà nel testo del programma. Molto meno spesso risulta:
Nel compilatore,
Sistema operativo,
Parte hardware,
· Collegamenti elettrici nell'edificio, ecc.
Ma se sei assolutamente sicuro che non ci siano errori nel programma, guarda i moduli standard a cui accede, scopri se la versione dell'ambiente di sviluppo è cambiata, alla fine basta riavviare il computer - qualche problema (soprattutto in ambienti DOS lanciati da in Windows) sono causati da un lavoro errato con la memoria.
8) Assicurati che il codice sorgente del programma corrisponda al codice oggetto compilato (il testo può essere modificato e il modulo eseguibile che stai testando è compilato dalla vecchia versione).
9) La ricerca ossessiva di un errore è quasi sempre controproducente. Se non funziona, rimanda l'attività, inizia a scrivere il modulo successivo o, nel peggiore dei casi, fai la documentazione.
10) Cerca di prenderti il \u200b\u200btempo per capire la causa dell'errore. Questo ti aiuterà:
Correggi il programma,
Rileva altri errori dello stesso tipo,
· Non farli in futuro.
11) Se conosci già i sintomi di un errore, a volte è utile non risolverlo subito, ma cercare altri bloopers sullo sfondo del comportamento noto del programma.
12) Gli errori più difficili da rilevare sono gli errori al passaggio del mouse, cioè quelli che sono stati introdotti nel codice durante la correzione di altri.
un override è la verifica dei risultati del test da parte del programma in fase di test
La bellezza di essere un programmatore ha molto a che fare con il debugging. Perché i programmatori violano i requisiti che conoscono: non fare commenti, non descrivere in dettaglio l'essenza del problema da risolvere e non seguire gli altri consigli utili... Molto spesso, il motivo è l'impazienza, preferirebbero vedere come funziona il programma, vedere i risultati del suo lavoro. Il debug è una sorta di processo investigativo. Sospettiamo che il programma appena creato non funzioni correttamente. La presunzione di innocenza qui non funziona. Se riusciamo a presentare un test su cui il programma dà un risultato errato, allora è dimostrato che i nostri sospetti sono corretti. Segretamente speriamo sempre che il programma funzioni correttamente la prima volta. Ma lo scopo del test è diverso: provare a confutare questa ipotesi. E solo allora, dopo aver corretto tutti gli errori identificati, ottieni un programma correttamente funzionante. Sfortunatamente, il debug non può garantire che il programma sia corretto, anche se tutti i test vengono superati. Il debug può provare che il programma non è corretto, ma non può provare che sia corretto.
L'arte di un tester è creare un sistema di test il più completo possibile che controlli tutti i possibili rami del calcolo. Spieghiamo questo con l'esempio più semplice. Lascia che il programma trovi la somma dei primi N elementi di un array X contenente M elementi. Oltre al test "normale", che verifica la situazione in cui 1
In precedenza abbiamo menzionato la legge "chechaco": un principiante può sospendere qualsiasi sistema. C'è una spiegazione per questo, inconsapevolmente, imposterà una delle improbabili combinazioni di dati di input (lavorando in un ambiente visivo, premerà il pulsante più inappropriato per una data situazione). Pertanto, un tester che esegue il debug dovrebbe essere in grado di assumere la posizione di un principiante, il sistema di test deve garantire che il programma funzioni correttamente non solo in "situazioni normali", ma ha anche "infallibile" e non porterà a un loop o interruzione in condizioni estreme situazioni probabili.
La difficoltà del debug sta nel fatto che, dopo aver trovato e corretto un errore, si ottiene un nuovo programma, per il quale è necessario riavviare il processo di debug, saltando nuovamente tutti i test. È noto che ci sono posti incantevoli nei programmi: la correzione di un errore porta alla comparsa di uno nuovo. In questi casi, la soluzione migliore è cercare un'altra soluzione al problema, fondamentalmente diversa.
Strumenti di debug
Alcuni errori di programma vengono rilevati automaticamente in fase di compilazione. Ciò include tutti gli errori di sintassi, errori di mancata corrispondenza del tipo e pochi altri. però sintatticamente corretto è necessario eseguire il debug del programma perché, sebbene i risultati dei calcoli siano stati ottenuti, non soddisfano le specifiche richieste. Il più delle volte, un programma che non è stato ancora sottoposto a debug funziona correttamente su alcuni dati iniziali e fornisce un risultato errato su altri. L'arte del debugging consiste nel trovare tutte le situazioni in cui il funzionamento del programma porta a calcoli errati. VBA ha strumenti molto sofisticati per il debug dei programmi, ad es. per rilevare errori nei programmi (test) e correggerli. Esistono due gruppi di strumenti VBA per aiutare un programmatore a identificare e correggere gli errori:
- Il primo gruppo consente di controllare il corso del processo di elaborazione, ad es. l'ordine degli operatori nelle procedure, l'ordine di chiamata delle procedure stesse. Se necessario, durante il processo di debug, è consentito modificare questo ordine, ad esempio è possibile saltare l'esecuzione di alcuni operatori o tornare alla loro esecuzione
- Il secondo gruppo di strumenti consente di controllare il cambiamento nello stato del processo computazionale (valori delle variabili e proprietà degli oggetti) durante l'esecuzione. E qui puoi intervenire e cambiare lo stato, impostando nuovi valori per alcune variabili lungo il percorso.
Prima di procedere con un esame dettagliato di questi strumenti, ricorda che durante il debug, un programma può trovarsi in uno dei tre stati: progettazione, calcolo e interruzione. Dopo aver terminato il disegno, è possibile avviare il programma per l'esecuzione. Dopo aver interrotto l'esecuzione del programma in un dato punto, entrati nello stato di interrupt, a questo punto è possibile verificare i valori delle variabili e delle proprietà degli oggetti e, se necessario, modificare questi valori "manualmente". In questo caso, è possibile modificare l'ordine degli operatori eseguiti, specificare il successivo operatore eseguibile, è possibile modificare il testo del programma prima di continuare il calcolo. La transizione dallo stato di calcolo allo stato di interruzione può avvenire per una serie di motivi, ad esempio, al raggiungimento di un punto di interruzione, quando una delle tante condizioni di interruzione è soddisfatta, a causa dell'esecuzione graduale del programma. Discuteremo tutte queste possibilità in seguito, ma ora considereremo un caso speciale. A volte un programma "si ripete" e deve essere forzato in uno stato di interruzione. Come si interrompe un programma in esecuzione? Basta premere la coppia di tasti Ctrl + Interrompi familiarità dal lavoro in DOS. Viene visualizzata la seguente finestra di dialogo con un messaggio di interruzione.
Debug (debug, debugging) - la fase di sviluppo del programma del computer, durante la quale gli errori vengono rilevati, localizzati ed eliminati. Per capire dove si è verificato l'errore, devi: scoprire i valori correnti delle variabili; scoprire su quale percorso era in esecuzione il programma.
Processo di debug inizia cercando di riprodurre il problema, che può essere difficile quando si programmano processi concorrenti o con alcuni errori insoliti noti come heisenbugs.
Tecnologie di debug.
1) Usa debugger - programmi che includono un'interfaccia utente per l'esecuzione passo passo di un programma: operatore per operatore, funzione per funzione, con fermate ad alcune righe di codice sorgente o al raggiungimento di una determinata condizione.
2) Visualizzazione dello stato corrente del programma utilizzando il punti critici programmi operatori di output - sullo schermo, stampante, altoparlante o file. L'output delle informazioni di debug in un file viene chiamato registrazione.
Strumenti di debug.
1. Debugger - uno strumento software che permette al programmatore di seguire l'esecuzione del programma in studio, fermarlo e riavviarlo, eseguirlo al rallentatore, modificare i valori in memoria e addirittura, in alcuni casi, tornare indietro nel tempo.
2. Profiler- consentono di determinare per quanto tempo viene eseguita una particolare sezione del codice e l'analisi della copertura rivelerà sezioni non eseguibili del codice.
3. Logger API- Consentire al programmatore di tracciare l'interazione tra il programma e l'API di Windows scrivendo i messaggi di Windows nel registro.
4. Disassemblatoriconsentire al programmatore di visualizzare il codice assembler del file eseguibile
5. Snifferaiutare il programmatore a tracciare il traffico di rete generato dal programma
6. Snifer dell'interfaccia hardwareti permetterà di vedere i dati scambiati tra il sistema e il dispositivo.
7. Registri di sistema.
Utilizzando linguaggi di programmazione di alto livellocome Java di solito rende più facile il debug perché contengono strumenti come la gestione delle eccezioni, facilitando notevolmente la ricerca della fonte del problema. In alcune lingue di basso livello come Assemblatore, i bug possono portare a problemi sottili come il danneggiamento della memoria o perdite di memoria e può essere difficile determinare cosa abbia causato il bug in primo luogo. In questi casi, potrebbero essere necessari trucchi sofisticati e strumenti di debug.
Debug \u003d Test + Ricerca di errori + Modifica
Tipi di debugSoftware, inclusi i test (nel nostro paese).
1.1. Autonomo debug. Test separati sequenziali di varie parti dei programmi inclusi nel software, con la ricerca e la correzione degli errori corretti durante il test. In realtà include il debug di ogni modulo del programma e il debug dell'accoppiamento del modulo.
1.2. Complesso debug . Test del software nel suo insieme, con la ricerca e la correzione degli errori registrati durante il test in tutti i documenti (inclusi i testi del programma software) relativi al software nel suo complesso. Tali documenti includono la definizione dei requisiti software, la specifica della qualità del software, la specifica del software funzionale, la descrizione del P.O. e testi di programmi software.
2.1. Sintattico debug. Gli errori di sintassi vengono rilevati dal compilatore, quindi è facile risolverli.
2.2. Semantico (semantico) debug. Arriva il momento in cui non ci sono più errori di sintassi, ma il programma produce risultati errati. Qui, il compilatore stesso non sarà in grado di rivelare nulla, sebbene nell'ambiente di programmazione ci siano solitamente aiuti per il debug, di cui parleremo più avanti.
Interrelazione dei processi di test e debug tramite l'algoritmo di debug.
Dopo che il codice funzionante è stato scritto, vengono eseguite esecuzioni di test del programma su vari set di dati di test.
In questo caso, il tester o programmatore deve ottenere in anticipo un risultato di controllo con il quale andrà la verifica del lavoro del codice testato.
Se si riscontrano discrepanze tra il controllo e i risultati effettivi, inizia la ricerca della sezione problematica del codice e l'identificazione degli errori nei modi sopra indicati.
Strumenti per il test automatico del codice sorgente dei programmi.
La tecnica principale qui è creare test del codice sorgente che verrà applicato al pezzo di codice testato e il sistema di test riporterà i risultati.
Esempi di tali sistemi includono il modulo doctest integrato in Python e la libreria di test multilingue xUnit, distribuita sotto i termini GNU / GPL e LGPL. La base per tutti questi strumenti e tecniche è suddividere un compito di grandi dimensioni in un numero di compiti chiari e più piccoli.
23. Principi di base della programmazione orientata agli oggetti: incapsulamento, ereditarietà, polimorfismo. La differenza tra l'approccio orientato agli oggetti e l'approccio modulare durante lo sviluppo dei programmi
Programmazione orientata agli oggetti (OOP) è un paradigma di programmazione in cui i concetti di base sono concetti oggetti e classi (o, in una versione meno nota dei linguaggi di prototipazione, prototipi).
Prototipo è un oggetto campione, a immagine e somiglianza di cui vengono creati altri oggetti.
Classe
Campi, descritti nella classe, vengono utilizzati per memorizzare i componenti dello stato dell'oggetto, ad es. i campi definiscono lo stato degli oggetti.
Metodi, descritti nella classe, determinano il comportamento degli oggetti. Ogni metodo determina la reazione dell'oggetto a un messaggio esterno o interno.
Un oggetto - variabile di tipo classe
I principi della programmazione orientata agli oggetti.
1. Astrazione.L'astrazione è un modo per evidenziare un insieme di caratteristiche significative di un oggetto, escludendo dalla considerazione quelle insignificanti. Di conseguenza, l'astrazione è una raccolta di tutte queste caratteristiche.
2. Incapsulamento.
L'incapsulamento è un principio OOP, in base al quale campi e metodi vengono combinati in una classe.
L'incapsulamento ti permette di delimitare l'accesso degli sviluppatori a vari campi e proprietà di una classe (simile a comeèfatto nei moduli Delphiquando solo la parte dell'interfaccia è visibile da altri moduli). Allo stesso modo, all'interno delle classi, alcuni campi e metodi possono essere resi liberamente disponibili per l'uso (visibili) ovunque nel programma, e altri campi e metodi possono essere resi disponibili solo all'interno del modulo corrente e dei metodi della classe. Ciò consente di nascondere le varie caratteristiche e capacità di una classe all'interno della descrizione, in modo che gli sviluppatori che riutilizzano la classe si concentrino sulle sue proprietà più importanti.
3. Eredità.L'ereditarietà è una proprietà del sistema che consente di descrivere una nuova classe basata su una esistente con funzionalità parzialmente o completamente prese in prestito.
L'ereditarietà è la capacità di costruire nuove classi più complesse da quelle esistenti aggiungendo campi e definendo nuovi metodi ( principio gerarchico).
Viene chiamata la classe da cui viene effettuata l'ereditarietà di base, genitore o superclasse. Nuova classe - discendente, un erede o una classe derivata. Il meccanismo di ereditarietà fornisce a una classe discendente la possibilità di utilizzare i campi e i metodi delle classi padre. Le catene di ereditarietà possono essere illimitato lunghezza. In questo caso sono consentiti metodi diversi per ciascuno degli eredi oltrepassare.
4. Polimorfismo.Il polimorfismo è una proprietà del sistema per utilizzare oggetti con la stessa interfaccia senza informazioni sul tipo e sulla struttura interna dell'oggetto.
Polimorfismo ("diversità") nella programmazione: la capacità di modificare il codice del programma in base al valore di alcuni parametri.
4.1. Puro polimorfismo - la possibilità di interpretare diversamente il codice della funzione a seconda del tipo di argomenti.
4.2. Funzioni di sovraccarico (nomi polimorfici) - la capacità di definire più funzioni con un nome; la scelta della funzione desiderata può essere determinata dai tipi di argomenti, ambito (all'interno di un modulo, file, classe, ecc.); se la scelta è determinata dal tipo di argomenti, viene chiamato l'overload parametrico.
4.3. Metodi di sostituzione - in OOP - la possibilità di differenti definizioni di metodi nella classe discendente e nella classe genitrice; il metodo concreto è determinato dalla classe dell'oggetto per il quale è chiamato. Quando si sostituiscono i metodi, viene fatta una distinzione tra polimorfismo semplice e complesso.
4.3.1. Polimorfismo semplice vengono utilizzati se, quando si chiama un metodo sovrascritto, il tipo di oggetto per il quale viene chiamato questo metodo è noto esattamente e, quindi, è noto con precisione quale metodo deve essere connesso: un metodo genitore o un metodo figlio. In questo caso, il metodo richiesto viene determinato in fase compilazione programmi.
4.3.2. Polimorfismo complesso vengono utilizzati se, quando si chiama un metodo sovrascritto, è necessario chiarire quale metodo deve essere connesso: un metodo genitore o un metodo figlio, poiché l'oggetto per il quale viene chiamato il metodo sovrascritto può essere un oggetto della classe genitore o un oggetto della classe figlia. In questo caso, il metodo richiesto viene determinato in fase compimento programmi quando il tipo di oggetto è noto esattamente.
4.4. Funzioni generalizzate (modelli) - la capacità di descrivere classi parametrizzate e modelli di funzioni, i parametri di tali descrizioni sono i tipi di argomenti di metodo o di funzione.
La differenza tra un approccio orientato agli oggetti e uno modulare.
1) Orientato agli oggetti approccio alla progettazione del software. prodotti basati su:
- selezione di classi di oggetti;
- stabilire le proprietà caratteristiche degli oggetti e le modalità della loro lavorazione;
- creare una gerarchia di classi, ereditando proprietà degli oggetti e metodi della loro elaborazione.
2) Programmazione modulare è l'organizzazione di un programma come un insieme di piccoli blocchi indipendenti, moduli, la cui struttura e comportamento obbedisce a determinate regole.
Si noti che il concetto di "modulo" non coincide in questo caso con il concetto di "modulo" (nel senso di "libreria") del linguaggio Pascal... Dovrebbe essere un'unità software (procedura o funzione) semplice, chiusa (indipendente), visibile, che implementa una sola funzione. Per scrivere un modulo, dovrebbe essere sufficiente una minima conoscenza del testo degli altri, sia chiamanti che chiamati.
Nella programmazione modulare dei prodotti software, vengono prima determinate la composizione e la subordinazione delle funzioni, quindi un insieme di moduli software che implementano queste funzioni.
24. Classi e oggetti: la loro definizione, il rapporto tra loro. Il ruolo dei componenti della classe: campi, proprietà, metodi. Specificatori di accesso pubblicati, pubblici, privati, protetti. Costruttori e distruttori, il loro ruolo. Eventi e loro utilizzo nella gestione del programma
Classe è un tipo di dati strutturali che include una descrizione dei campi dati, nonché procedure e funzioni che funzionano con questi campi dati (metodi).
Un oggetto - variabile di tipo classe - un'entità nello spazio degli indirizzi di un sistema informatico che appare quando si crea un'istanza di una classe (ad esempio, dopo aver eseguito i risultati della compilazione (e del collegamento) del codice sorgente per l'esecuzione).
Relazione classe-oggetto:
Il concetto di classe è più generale di quello di oggetto. Object è un'istanza di una classe... Una classe può essere vista come una raccolta di oggetti (proprio come un insieme è una raccolta di elementi). Una classe può essere atomica o suddivisa (proprio come un insieme è suddiviso in sottoinsiemi). Ad esempio, la classe PERSON contiene una sottoclasse STUDENT, che a sua volta contiene un oggetto John_Smith.
Le classi hanno(ad esempio in Delphi):
− Campo classe ( attributo) in OOP: una variabile associata a una classe o un oggetto. Campi, descritti nella classe, vengono utilizzati per memorizzare i componenti dello stato dell'oggetto, ad es. i campi definiscono lo stato degli oggetti. Si accede ai campi in base al nome.
− Metodidescritte nella classe (le subroutine che elaborano i campi e le proprietà della classe) determinano il comportamento degli oggetti. Ogni metodo determina la reazione dell'oggetto a un messaggio esterno o interno.
− Proprietà - un modo per accedere allo stato interno di un oggetto, imitando una variabile di qualche tipo. L'accesso a una proprietà dell'oggetto viene implementato tramite una chiamata di funzione. Quando si tenta di impostare il valore di questa proprietà, viene chiamato un metodo e quando si tenta di ottenere il valore di questa proprietà, viene chiamato un altro metodo.
Vengono chiamati i campi, le proprietà e i metodi della classe membri della classe.
La variabile descritta come classe è in realtà puntatore a un'istanza della classe. In un programma orientato agli oggetti che utilizza classi, ogni oggetto è un '"istanza" di una classe particolare e non vengono forniti altri oggetti.
Specificatori di accesso pubblicati, pubblici, privati, protetti.
L'incapsulamento è una proprietà di sistema che consente di combinare dati e metodi che funzionano con esso in una classe e nascondere i dettagli di implementazione all'utente.
Per impostazione predefinita (in Delphi) la visibilità dei membri della classe genitore è esattamente ereditata, tuttavia è consentita sollevare visibilità: rendere più accessibili campi, proprietà e metodi. La visibilità ridotta non è consentita.
Livelli di incapsulamento(accessibilità di eventuali membri della classe):
1) Pubblico... I membri della classe in questa sezione sono accessibili da qualsiasi punto del programma.
2) Privato... I membri della classe sono disponibili solo nel modulo in cui è descritta la classe. Per impostazione predefinita, si considera che tutti i campi della classe si trovino nella sezione privato.
3) Protetto... I membri della classe sono disponibili nel modulo in cui viene descritta la classe, nonché all'interno dei metodi delle classi che ereditano da questa classe e descritte in altri moduli.
4) Pubblicato... I membri della classe in questa sezione sono accessibili da qualsiasi punto del programma. Questa sezione contiene le proprietà della classe: campi disponibili per la modifica e la modifica dei valori in fase di progettazione e da Ispettori degli oggetti.
5) Automatizzato... I membri della classe in questa sezione sono accessibili da qualsiasi punto del programma. Le descrizioni possono essere inserite in questa sezione solo se la classe eredita dalla classe standard TAutoObject(in Delphi), progettato per creare i cosiddetti server di automazione utilizzando la tecnologia COM (Competent Object Model).
Costruttori e distruttori.
quando oggetto viene creato, un metodo speciale chiamato costruttore... Esegue varie azioni per inizializzare i campi dell'oggetto.
quando l'oggetto viene distrutto (ad esempio, è stato descritto all'interno della procedura come una variabile locale e viene rimosso dalla memoria quando finisce), viene chiamato un altro metodo - distruttoreche esegue varie azioni aggiuntive per liberare memoria, se necessario.
Eventi e loro utilizzo nella gestione del programma.
Un evento OOP è un messaggio che si verifica in vari punti del codice eseguibile quando vengono soddisfatte determinate condizioni.
Gli eventi sono progettati per essere in grado di anticipare la risposta del software.
Per risolvere il compito impostato, gestori di eventi: non appena il programma entra nello stato specificato, si verifica un evento, viene inviato un messaggio e il gestore intercetta questo messaggio.
25. Le principali differenze tra Object Pascal (Delphi) e Turbo Pascal. Array dinamici in Delphi: descrizione, caratteristiche, applicazione
Turbo pascal - un ambiente di sviluppo integrato per il linguaggio di programmazione Pascal e un linguaggio di programmazione in questo ambiente, un dialetto Pascal di Borland.
Delphi - un ambiente di programmazione che utilizza il linguaggio di programmazione Object Pascal.
Object Pascal è il risultato dello sviluppo del linguaggio Turbo pascal, che a sua volta si è sviluppato dalla lingua Pascal. Pascal era un linguaggio completamente procedurale.
Turbo pascaldalla versione 5.5 aggiunta in Pascal orientato agli oggetti proprietà, e in Object Pascal - identificazione dinamica di un tipo di dati con la possibilità di accedere ai metadati delle classi (cioè alla descrizione delle classi e dei loro membri) nel codice compilato, chiamato anche introspezione - questa tecnologia ha ricevuto la designazione RTTI.
Poiché tutte le classi ereditano le funzioni della classe TObject di base, qualsiasi puntatore a un oggetto può essere convertito in esso, quindi utilizzare il metodo ClassType e la funzione TypeInfo, che fornirà l'introspezione.
Object Pascal ( Delphi) è il risultato dell'estensione funzionale Turbo Pascal.
Il modello a oggetti Delphi Pascal è più completo del modello utilizzato da Borland Pascal 7.0:
- limitare l'accesso a campi e metodi definendo la propria interfaccia per ogni campo della classe (cinque tipi di sezioni quando si dichiara una classe, utilizzando le proprietà);
- meccanismi più avanzati per l'implementazione di metodi polimorfici (metodi astratti, dinamici) ",
- strumenti per lavorare con le metaclassi (variabili metaclasse, metodi di classe, meccanismo RTTI).
Array dinamici in Delphi.
Vettore è un insieme ordinato di dati. Dinamico chiamato array, la cui dimensione può cambiare durante l'esecuzione del programma.
Anno Domini Vettore: var My_Array: array di BaseType;
Con questa dichiarazione, non viene allocata alcuna memoria e la dimensione iniziale dell'array è zero.
Impostazione delle dimensioni Vettore: SetLength (My_Array, 100);
Ottenere il numero di elementi Vettore: n: \u003d Lunghezza (My_Array);
Riferendosi al primo elemento Vettore: My_Array: \u003d 10; x: \u003d My_Array;
Dichiarazione 2D Vettore: var A: array di array di BaseType;
Se si assegna un array dinamico a una variabile, il suo contenuto non viene copiato, viene assegnato solo un puntatore all'array. Ma se ti applichi a un nuovo array SetLength, quindi verrà eseguita la copia.
26. La struttura dei moduli a Delphi. Interfaccia, parti eseguibili, parti di inizio e fine. Procedure e funzioni: caratteristiche in Delphi
Un progetto Delphi è una raccolta di unità di programma - moduli.
Delphi ti permette di mettere le tue funzioni e procedure in un file separato modulo (Unità), quindi utilizzare le procedure e le funzioni del modulo nei propri programmi, specificando il nome del modulo nell'elenco dei moduli richiesti dal programma (istruzione usi). Un modulo è un file con estensione * .pas.
Il modulo inizia con un'istruzione di intestazione unità, che contiene il nome del modulo.
Il modulo è costituito da una sequenza di sezioni... Ogni sezione inizia con una parola chiave e continua fino all'inizio della sezione successiva. Alla sezione implementazione (implementazione) è necessario inserire le procedure e le funzioni dichiarate nella sezione interfaccia.
Struttura del modulo Delphi.
Unità<имя>;
Interfaccia <интерфейсная часть>
Implementazione <исполняемая часть>
inizializzazione <инициирующая часть>
finalizzazione <завершающая часть>
La parte iniziale e quella finale sono spesso assenti... NEL iniziando le parti sono istruzioni che vengono eseguite prima che il controllo venga trasferito al programma principale e vengono solitamente utilizzate per prepararne il lavoro. NEL il finale vengono specificate parti, istruzioni che vengono eseguite dopo che il programma principale è terminato (in cui le risorse allocate al programma vengono rilasciate, i file vengono chiusi, ecc.).
unità Nome modulo;
interfaccia // sezione interfaccia
(Descrizioni delle procedure e delle funzioni del modulo che possono essere utilizzate da altri moduli.)
const // sezione dichiarazione delle costanti
(Dichiarazioni delle costanti globali del modulo che possono essere utilizzate dalle procedure e dalle funzioni del modulo.)
genere // dichiarazioni di tipo distribuito
(Dichiarazioni di tipi di moduli globali che possono essere utilizzati dalle procedure e dalle funzioni del modulo)
var // sezione dichiarazione di variabili
(Dichiarazioni delle variabili globali del modulo che possono essere utilizzate dalle procedure e dalle funzioni del modulo)
implementazione // sezione implementazione
(Descrizioni (testo) delle procedure e delle funzioni del modulo!}
Utilizzando il modulo.Affinché il programma possa utilizzare le funzioni e le procedure del modulo, è necessario aggiungere questo modulo al progetto e specificare il nome del modulo nell'elenco dei moduli utilizzati. Dopo aver aggiunto il nome del modulo all'elenco dei moduli utilizzati dall'applicazione, il modulo stesso deve essere aggiunto al progetto.
Procedure e funzioni in Delphi.
Procedura - una subroutine che esegue alcune azioni e che può essere richiamata da altre parti del programma. Dopo aver eseguito la procedura, il programma continua l'esecuzione dal punto da cui è stato chiamato.
Una procedura è una sorta di subroutine. Tipicamente, una subroutine viene implementata come procedura in due casi:
- quando la subroutine non restituisce alcun dato al programma principale;
- quando una subroutine restituisce più di un valore al programma chiamante.
Parametri È l'input.
Dichiarazione di procedura
procedura NomeProcedura (var parametro1: tipo1;… var parametro K: tipo K);
