Sommario Obiettivi Tesi Argomenti Trattati Lavoro svolto

Presentazione sul tema: "Sommario Obiettivi Tesi Argomenti Trattati Lavoro svolto"— Transcript della presentazione:

1 Sommario Obiettivi Tesi Argomenti Trattati Lavoro svolto
metriche del software(cenni) metriche OO Punti Funzione

2 Metriche del software In generale le metriche del software sono utili per: Migliorare il processo software Pianificare, seguire e controllare l’andamento di un progetto Valutare la qualità di un prodotto Stimare lo sforzo richiesto per sviluppare un sistema software

3 Le metriche del software dovrebbero essere:
Semplici Oggettive Ottenibili ad un costo ragionevole Valide Robuste

4 LOC – Line of Code 1/2 è la metrica dimensionale più semplice e conta tutte le line fisiche del codice sorgente. NCNB (conteggia tutte le linee effettive del codice sorgente, non sono conteggiate le linee di commento e quelle vuote) EXEC (conta solo le linee di comando del codice indipendentemente dalle linee fisiche )

5 LOC – Line of Code 2/2 CLOC (conta solo le line di commento del codice ) CP (la percentuale di linee di commento rispetto a tutte le linee di codice (escluse le linee vuote)

6 Complessità Ciclomatica 1/2
usata per valutare la complessità di un algoritmo ed è interamente basata sulla struttura del grafo che rappresenta l’algoritmo. V(G): numero ciclomatico relativo al grafo G L: numero di archi nel grafo N: numero di nodi del grafo P: numero dei componenti del grafo disconnessi

7 Complessità ciclomatica 2/2
V(G) = L- N + 2*P V(G) = n° nodi decisionali +1

8 Function Point /3 I Function Point sono una metrica del software di tipo "funzionale", cioè definiscono le dimensioni del prodotto software in termini di funzionalità fornite all'utilizzatore. Vantaggi: Sono orientati alla misurazione del prodotto finale dello sviluppo software (le funzionalità) e quindi risultano utili per definire quantitativamente il prodotto a fini contrattuali Sono indipendenti dagli aspetti tecnologici e metodologici

9 Function Point 2/3 Possono essere utilizzati già nelle fasi alte del processo di sviluppo del software, per effettuare stime e previsioni, ma anche per valutare la dimensione di un'applicazione appena terminata o già in produzione. Risultano utili per ricavare indicatori di efficienza riguardo le attività di sviluppo e manutenzione del software Sono riconosciuti in ambito internazionale e supportati da organismi istituzionali: IFPUG, GUFPI , NESM Sono correlabili ai LOC (Lines Of Code), attraverso tabelle di conversione

10 Fuction Point 3/3 Svantaggi:
Non sono particolarmente sensibili alle peculiarità delle applicazioni "embedded" (tipo ERP) e Real-Time Un conteggio standard richiede un buon livello di definizione funzionale del sistema Occorre acquisire una buona conoscenza (ed un minimo di esperienza pratica) del metodo di conteggio

11 Metriche OO Le metriche orientate agli oggetti si concentrano sulla classe, l’elemento fondamentale della programmazione orientata agli oggetti. Chidamber e Kemerer nel 1994 definirono sei metriche basate sulla classe, spesso collettivamente denominate CK

12 WMC (Weighted Methods per Class) 1/2
è il numero di metodi per classe, pesati secondo la rispettiva complessità. Supponiamo che in una classe C ciano definiti n metodi, di complessità c1,c2,…,cn. (Chidamber e Kemerer non indicano come misurare la complessità di ciascun metodo)

13 WMC (Weighted Methods per Class) 2/2
Considerazioni: Maggiore è tale numero, maggiore sarà il tempo e lo sforzo necessario per sviluppare e gestire la classe, maggiore sarà il potenziale impatto sulle classi derivate, minori saranno le possibilità di riuso della classe: la classe sarà specifica per l’applicazione per la quale è stata progettata. Per questi motivi, si deve cercare di mantenere WMC il più basso possibile.

14 DIT (Depth of Inheritance Tree)
è la distanza (numero di livelli) della classe dalla radice della gerarchia di ereditarietà cui appartiene. Considerazioni: Tanto maggiore è DIT, tanto più grande è il numero di metodi ereditati e quindi l’influenza delle proprietà degli antenati sulla classe. Per le classi con DIT grande è quindi più difficile prevedere il comportamento della classe, ma è potenzialmente maggiore il riuso dei metodi ereditati

15 NOC (Number Of Children)
il numero di sottoclassi che ereditano direttamente dalla classe considerata Considerazioni: Un valore grande di NOC indica un grande impatto sui discendenti, e un riuso potenzialmente elevato della classe. Questo indica criticità nella progettazione della classe (che deve essere una generalizzazione corretta di tutte le classi discendenti) e la necessità di maggiore attenzione in fase di verifica.

16 CBO (Coupling Between Object classes) 1/2
è il numero di classi accoppiate alla classe considerata, considerando accoppiate le classi fra cui esiste dipendenza diretta (ad esempio, l’una accede alle proprietà dell’altra). Considerazioni: Un valore di CBO eccessivo indica scarsa modularità, mancanza di indipendenza e difficoltà di riuso.

17 CBO (Coupling Between Object classes) 2/2
Considerazioni valori alti di CBO implicano elevata sensibilità alle modifiche (gli effetti del cambiamento in una classe si propagano a quelle accoppiate) il CBO è indice della complessità del testing

18 RFC (Response For a Class)
è il numero di metodi che possono essere invocati in risposta alla ricezione di un messaggio da parte di un’istanza della classe considerata. RFC indica la complessità di una classe in base al numero dei metodi e la quantità di comunicazione con le altre classi. Considerazioni: Al crescere di RFC cresce la complessità della classe e la difficoltà del testing e debugging

19 LCOM (Lack of COhesion in Methods) 1/2
misura la coesione della classe considerata, in base al numero di coppie di metodi che accedono ad un insieme comune di attributi della classe. Più precisamente LCOM è il numero delle coppie di metodi che non hanno variabili in comune meno il numero di coppie di metodi che hanno variabili in comune, quindi due metodi di una classe sono tanto più coesi quanto più numerose sono le variabili usate da entrambi i metodi.

20 LCOM (Lack of COhesion in Methods) 2/2
Considerazioni: La coesione è desiderabile poiché promuove l’incapsulamento. Quando molte classi presentano un valore di LCOM scarso il sistema è caratterizzato da una struttura complessa più soggetta a errori. Un valore di LCOM scarso suggerisce di rivedere la progettazione della classe, eventualmente dividendola in due classi distinte.

21 Altre metriche 1/4 Metriche di Lorenz e Kidd 1994
Class size - CS (dimensione complessiva di una classe ) Number of Overridden Operations - NOO (misura il numero di operazioni ridefinite da una sottoclasse) number of operations added by a subclass - NOA (il numero di operazioni aggiunte da una sottoclasse )

22 Altre metriche 2/4 number of scenario scripts - NSS (è il numero di scenari, o casi d’uso) Specialization Index - SI (indica approssimativamente il grado di specializzazione di una classe) Number of Key Classes - NKC misura il numero di classi che sono legate direttamente al problema

23 Altre Metriche 3/4 Le metriche MOOD
MIF (Method Inheritance Factor): il grado con il quale l'architettura della classe di un sistema OO usa l'ereditarietà per i metodi e gli attributi CF (Coupling Factor): fattore di accoppiamento PF (Polymorrphism Factor): il numero di metodi che ridefiniscono i metodi ereditati, divisi per il numero massimo delle possibili situazioni polimorfiche

24 Altre Metriche 4/4 Le metriche di Cartwright e Shepperd
Numero di attributi Numero di stati Numero di eventi cui la classe è sensibile Numero di accessi alla classe Profondità nell’albero di ereditarietà (DIT) Numero di figli (NOC) Numero di difetti Numero di righe di codice

25 Punti Funzione e metodologia orientata agli oggetti
varianti ad hoc per avvicinare le metriche funzionali al mondo OO: Object Points Object Points Analysis Function Points con OO Use Cases e OO Object-Oriented Function Points Use Case Points Enhanced Object Points

26 Conteggio FP 1/2

27 Conteggio FP 2/2