PPX.3 Astrazione Procedurale e Specifiche .

Totale vs Parziale:

Una procedura è totale se può essere eseguita correttamente su qualsiasi input valido.

Una procedura è parziale se può fallire su alcuni input o contesti anche se ammessi come parametri (per esempio, se richiedi n numeri e ne fornisci di meno).

I vincoli hanno senso solo se evitano situazioni di errori che il programma nn sa gestire o che semplicemente vanno contro le indicazioni della consegna.

ATTENZIONE: i vincoli hanno senso solo se l’inpt può causare errori di sistema oppure in caso di esplicite condizioni del problema da risolvere, non per semplificare l’implementazione a piacere (a meno che sia ammesso)

2 MECCANISMI DI ASTRAZIONE PRINCIPALI

(cosa dobbiamo fare, non come implementarlo)

PER PARAMETRIZZAZIONE (astrazione sul dato)

focus sul tipo di valori e non sui valori effettivi

PER SPECIFICA (astrazione sui vincoli dell’operazione, cosa devo ottenere?)

focus su quello che devo fare, non su come farlo (se devo fare la radice quadrata, posso implementarlo in diversi modi)

VANTAGGI

LOCALITA’: astrazioni indipendenti tra di loro

MODIFICABILITA’: posso modificare il programma senza cambiare il modo di usare il codice, l’utente nn si rende conto che è cambiato il codice

TIPI DI ASTRAZIONE

SUI DATI

PROCEDURALE

DI ITERAZIONE

GERARCHIE DEI TIPI

ASTRAZIONE PROCEDURALE

COME USARE UN LINGUAGGIO DI SPECIFICA

le specifiche possono essere anche in un linguaggio informale ma deve essere chiaro

in laboratorio dobbiamo partire dalle specifiche (dopo aver definito la signature dei metodi)

anche in fase di esame

LISKOV

4 campi da scrivere

REQUIRES: specifica i possibili vincoli sugli input (ad esempio la radice quadrata ammette solo i valori positivi)

MODIFIES: l’input è modificato dalla procedura, e devo spiegare cosa viene modificato.

Se io faccio una funzione che calcola la somma tra 2 numeri e li passo in input, restituisco la somma e quindi la funzione è pura (senza effetti collaterali, allora si omette questo campo)
ma non è sempre così, posso cambiare qualcosa di globale, un dato esterno al metodo, per causa della funzione

EFFECTS: spiega l’ouput (ci deve essere sempre)

OVERVIEW: funzionalità chiave di una classe

ESEMPIO

ad un certo punto modifico l’array, lo ordino senza alcun return, quindi avviso

PROPRIETA DELLE SPECIFICHE (lo chiede all’esame)

RESTRIUTTIVITA’: riferirmi solo e integralmente alle implementazioni corrette (restrittivo ma senza escludere info importanti)

MINIMALITA’: meno vincoli possibile sul come implementare

generalità
sotto-determinazione: mi permette di contemplare scenari non specificati e avere la garanzia che non impatteranno sull’implementazione finche nn sono stati specificati
comportamento non deterministico: nei termini del risultato atteso

comportamento deterministico è sempre preferito

CHIAREZZA

PROPRIETA DELLE PROCEDURE (lo chiede all’esame)

PROCEDURE → in questo contesto, il termine "procedure" si riferisce generalmente ai metodi in programmazione. La terminologia può variare, ma i concetti di semplicità, generalità, e le caratteristiche delle procedure totali e parziali sono comunemente discussi nel contesto dei metodi e delle funzioni.

SEMPLICITA’

se fatico a formulare un nome semplice, probabile non è semplice
chiarezza su cosa fa la procedura

se ho una procedura che fa 2 cose, trovare un buon nome nn è scontato, quindi spezzo in 2 procedure

GENERALITA’:

conosco l’insieme di input su cui si applica la procedura
ad esempio se spiego che sommo 10 ad un età, oppure dico che sommo un valore generico ad un età…sono 2 generalità differenti

2 CARATTERISTICHE DELLE PROCEDURE

PROCEDURE TOTALI: senza alcun vincolo sull’input(dominio)

non richiedono requires, pk l’unico controllo da fare sarà il tipo di input e ci pensa il compilatore
il risultato deve essere valido e prevedile, se gestisco le eccezioni devo specificarlo

PROCEDURE PARZIALI: hanno dei vincoli

uso REQUIRES
se metto un input al di fuori del vincolo può letteralmente succedere qualcosa, l’errore non è gestito, pk è fuori vincolo appunto ma deve essere deterministico, ovvero comportarsi nello stesso modo “anomalo” ogni volta

NOTA BENE:

se io non metto un vincolo, e ci dovrebbe essere, chi usa il programma nn lo sa quindi devo modificare l’implementazione per renderlo totale, idem se chi legge un requires nota che manca una informazione, dovrà implementare diversamente pk fare eventuali controlli/verifiche
le procedure parziali sono più performanti, le procedure totali sono più semplici e sicure