Complessità di programmazione - Programming complexity

La complessità di programmazione (o complessità del software ) è un termine che include molte proprietà di un pezzo di software, che influenzano tutte le interazioni interne. Secondo diversi commentatori, esiste una distinzione tra i termini complesso e complicato. Complicato implica essere difficili da capire ma con tempo e fatica, in ultima analisi, conoscibili. Complesso, d'altra parte, descrive le interazioni tra un numero di entità. All'aumentare del numero di entità, il numero di interazioni tra di loro aumenterebbe in modo esponenziale e arriverebbe a un punto in cui sarebbe impossibile conoscerle e comprenderle tutte. Allo stesso modo, livelli più elevati di complessità nel software aumentano il rischio di interferire involontariamente con le interazioni e quindi aumenta la possibilità di introdurre difetti quando si apportano modifiche. In casi più estremi, può rendere virtualmente impossibile la modifica del software. L'idea di collegare la complessità del software alla manutenibilità del software è stata ampiamente esplorata dal professor Manny Lehman , che ha sviluppato le sue leggi dell'evoluzione del software dalla sua ricerca. Lui e il suo coautore Les Belady hanno esplorato numerose possibili metriche del software nel loro libro spesso citato, che potrebbero essere utilizzate per misurare lo stato del software, giungendo alla conclusione che l'unica soluzione pratica sarebbe quella di utilizzare una che utilizza la complessità deterministica Modelli.

Le misure

Sono state proposte molte misure di complessità del software. Molti di questi, sebbene forniscano una buona rappresentazione della complessità, non si prestano a una facile misurazione. Alcune delle metriche più comunemente utilizzate sono

Metrica della complessità ciclomatica di McCabe
Metriche di scienza del software di Halsteads
Henry e Kafura hanno introdotto le metriche della struttura del software basate sul flusso di informazioni nel 1981, che misura la complessità in funzione del fan in e del fan out. Definiscono il fan-in di una procedura come il numero di flussi locali in quella procedura più il numero di strutture di dati da cui quella procedura recupera le informazioni. Il fan-out è definito come il numero di flussi locali in uscita da quella procedura più il numero di strutture dati che la procedura aggiorna. I flussi locali si riferiscono ai dati passati ae da procedure che chiamano o sono chiamate dalla procedura in questione. Il valore di complessità di Henry e Kafura è definito come "la lunghezza della procedura moltiplicata per il quadrato del fan-in moltiplicato per il fan-out" (Lunghezza × (fan-in × fan-out) ²).
Una suite di metriche per la progettazione orientata agli oggetti è stata introdotta da Chidamber e Kemerer nel 1994 concentrandosi, come suggerisce il titolo, sulle metriche specifiche per il codice orientato agli oggetti. Introducono sei metriche di complessità OO; metodi ponderati per classe, accoppiamento tra classi di oggetti, risposta per una classe, numero di figli, profondità dell'albero di ereditarietà e mancanza di coesione dei metodi

Esistono molte altre metriche che possono essere utilizzate per misurare la complessità della programmazione:

Complessità ramificata (metrica Sneed)
Complessità dell'accesso ai dati (Card Metric)
Complessità dei dati (metrica Chapin)
Complessità del flusso di dati (metrica Elshof)
Complessità decisionale (metrica McClure)

La legge di Tesler è un adagio nell'interazione uomo-computer che afferma che ogni applicazione ha una quantità intrinseca di complessità che non può essere rimossa o nascosta.

Tipi

Associata e dipendente dalla complessità di un programma esistente, è la complessità associata alla modifica del programma. La complessità di un problema può essere suddivisa in due parti:

Complessità accidentale: si riferisce alle difficoltà che un programmatore deve affrontare a causa degli strumenti di ingegneria del software scelti. Un set di strumenti più adatto o un linguaggio di programmazione di alto livello possono ridurlo. La complessità accidentale è spesso anche una conseguenza del mancato utilizzo del dominio per inquadrare la forma della soluzione, cioè il codice. Una pratica che può aiutare a evitare la complessità accidentale è la progettazione guidata dal dominio .
Complessità essenziale: è causata dalle caratteristiche del problema da risolvere e non può essere ridotta.

Metriche di Chidamber e Kemerer

Chidamber e Kemerer hanno proposto una serie di metriche di complessità di programmazione, ampiamente utilizzate in molte misurazioni e articoli accademici. Sono WMC, CBO, RFC, NOC, DIT e LCOM, descritti di seguito:

WMC: metodi ponderati per classe
- ${\ displaystyle WMC = \ sum _ {i = 1} ^ {n} c_ {i}}$
- n è il numero di metodi sulla classe
- ${\ displaystyle c_ {i}}$ è la complessità del metodo
CBO - accoppiamento tra classi di oggetti
- numero di altra classe che è accoppiata (utilizzando o in uso)
RFC - risposta per una classe
- ${\ displaystyle RFC = | RS |}$ dove
- ${\ displaystyle RS = \ {M \} \ cup _ {all \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ è un insieme di metodi chiamati dal metodo i
- ${\ displaystyle M}$ è l'insieme di metodi nella classe
NOC - numero di bambini
- somma di tutte le classi che ereditano questa classe o un suo discendente
DIT - profondità dell'albero dell'ereditarietà
- profondità massima dell'albero di ereditarietà per questa classe
LCOM- mancanza di coesione dei metodi
- Misura l'intersezione degli attributi usati in comune dai metodi di classe
- ${\ displaystyle LCOM = {\ begin {cases} | P | - | Q |, & {\ text {if}} | P |> | Q | \\ 0, & {\ text {else}} \ end {cases }}}$
- Dove ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- E ${\ displaystyle Q = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} \ neq \ emptyset \}}$
- With è l'insieme di attributi (variabili di istanza) a cui si accede (letti o scritti) dal metodo -th della classe ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$