CAST Imaging e le Management&Engineering Dashboard di CAST forniscono numerose regole e metriche che riguardano il disegno architetturale delle applicazioni. La misurazione di queste metriche è resa possibile dal motore di analisi statica che identifica nel codice sorgente tutti gli artefatti nei differenti linguaggi di programmazione e le loro interazioni sia di tipo Call (invocazione diretta di un metodo nel codice di un altro metodo) sia ti tipo Inheritance (derivazione di classi per linguaggi Object Oriented), sia di tipo Access (per l’accesso ai dati) o Reference generica (dipendenza di una componente da un’altra).
Queste informazioni, raccolte preliminarmente durante l’analisi statica del codice sorgente, possono poi essere sfruttate per misurare ed evidenziare eventuali problematiche di tipo architetturale, che dipendono quindi non dalla singola riga di codice o dal singolo componente, ma proprio dal modo in cui è disegnata e organizzata l’interazione dei componenti software.
Passiamo quindi in rassegna alcune tipiche problematiche architetturali che possono essere individuate e prevenute grazie all’uso dei tool di CAST.
Dipendenze Cicliche
Quando due package (o namespace) si riferiscono l’un l’altro tramite una chiamata (link di tipo Call), il risultato è una dipendenza circolare. Nessuno dei due pacchetti può funzionare senza l'altro, quindi nessuno dei due è riutilizzabile senza l'altro. In alcuni casi rivedere il disegno architetturale permette di eliminare queste dipendenze. Quando riferimenti circolari sono necessari, è comunque auspicabile rivedere la progettazione per favorire il più possibile la modularità del codice ed il suo riutilizzo.
Lo stesso problema si verifica quando alcune classi da un pacchetto A ereditano dalle classi di un pacchetto B (link di tipo Inheritance) e altre classi dal pacchetto B ereditano da classi dal pacchetto A. Questa regola può essere estesa a dipendenze circolari per più di 2 pacchetti (ad esempio un pacchetto A chiama un pacchetto B che chiama un pacchetto C che chiama un pacchetto A). Attenzione però che avere una dipendenza ciclica non significa necessariamente che venga generato un loop infinito o che si generi un problema di blocco dell’applicazione a run-time: significa soltanto che non è possibile scomporre in modo modulare e deployare separatamente diverse parti dell’applicazione in un’ottica di riutilizzo del codice e segregazione funzionale.
Il quality model di CAST fornisce diverse regole che riguardano questa problematica per differenti stack tecnologici:
- Avoid cyclical calls and inheritances between packages (J2EE)
- Avoid cyclical calls and inheritances between namespaces content (.NET)
- Avoid Include Circular references (SAP)
- Avoid cyclic references in the definition of CDS views (S4/HAHA)
- Avoid header files circular references (C/C++)
Duplicazione del codice
La pratica del copia-incolla è molto diffusa tra gli sviluppatori, soprattutto quando il codice sorgente viene ereditato o passato da un team all’altro. Questo approccio non è sempre sbagliato e può dare vantaggi immediati per rispondere in fretta alle richieste di nuove fuinzionalità. Diventa senz’altro molto pericoloso a medio-lungo termine, facendo anche lievitare i costi di maintenance dell’applicazione. Proviamo ad immaginare un’applicazione dove lo stesso campo si trova in una decina di classi diverse, ogni volta che si dovrà fare una modifica andrà riportata su ciascuna classe, con il rischio di non riuscire più ad individuare tutti i punti in cui le modifiche vanno apportate. Un programma con molta duplicazione di codice è sempre più difficile da modificare e far evolvere. Con il tempo questa pratica porta al fenomeno di “erosione del codice”, rende sempre più costoso e rischioso mantenere un’applicazione fino a causarne la dismissione.
Il quality model di CAST fornisce alcune metriche per tenere sotto controllo il codice duplicato:
- Avoid Too Many Copy Pasted Artifacts (ALL TECNOLOGIES)
L’algoritmo di individuazione del copia-incolla di CAST è basato su un metodo di rilevamento statistico. Il metodo statistico calcola una metrica di similarità tra tutti gli artefatti identificati nell’applicazione dagli analizzatori di CAST. Gli artefatti sono segnalati come violazione per il copia-incolla quando la similarità tra loro è superiore ad una cera soglia (per default il parametro SIMILARITY è impostato al 90%). Per un'efficienza ottimale, il rilevamento del codice copia-incollato è abilitato solo per artefatti superiori a 10 righe di codice (metodi, funzioni, procedure, trigger, programmi...).
- Copy Pasted Code (% of LOC)
L’algoritmo è lo stesso della regola precedente, ma, in questo caso, per ciascun modulo dell’applicazione viene fornito il rapporto tra il numero di righe di codice di tutti gli artefatti copiati/incollati diviso per il numero totale di righe di codice di tutti gli artefatti inclusi nel modulo.
- Reuse by Call Distribution
Questa metrica misura il numero di chiamanti di un artefatto: più sono i chiamanti più significa che lo stesso codice viene riutilizzato per rispondere a diverse funzionalità, al variare dei parametri forniti. Viene restituita la distribuzione degli artefatti in base al numero di metodi chiamanti, la distribuzione suddivide gli artefatti in 4 classi in base al numero di chiamanti: livello di riutilizzo basso (fino a 4 chiamanti), medio (da 4 a 10 chiamanti), alto (da 10 a 30), molto alto (sopra 30 chiamanti).
Per una rassegna esaustiva di tutte le metriche che riguardano l’Architectural Design (come per tutte le altre regole fornite nel Quality Model di CAST) si può far riferimento alla seguente documentazione online:
https://technologies.castsoftware.com/rules
Comments: