Come spiegato nella prima parte di questo articolo, una Architettura Software è l’impianto di base di una piattaforma applicativa, e deve essere strutturata bene e poter reggere nel tempo anche a richieste nuove senza dover stravolgere la base.
Sono le fondamenta su cui si basa la costruzione del software sovrastante.
Una parte di questa è l’analisi (la struttura del database e delle tabelle, e come si relazionano una con l’altra) e l’altra è il software di base (framework ed oggetti con cui i programmatori si relazioneranno nella costruzione delle procedure).

Per realizzare il software di base, occorre tener presente la teoria generale con cui deve essere realizzato tale progetto.
Una struttura con più strati di software, e con un buon grado di astrazione, permette una gestione migliore ed una testabilità delle singole componenti di cui si compone il Framework di base.
Una procedura di base si può dividere in 3 livelli :

Data Access Layer : è lo strato che si interfaccia ai dati della procedura, normalmente al Database.

Business Logic Layer : è lo strato con gli oggetti che si interfacciano con i dati tramite lo strato di accesso ai dati, e che forniscono supporto all’interfaccia utente.

Presentation Layer : è lo strato dell’interfaccia utente finale, quello che interagisce con l’utilizzatore del programma, e che accede ai dati tramite lo strato di Business Layer o direttamente con lo strato della logica dei dati.

 

Il primo strato viene fornito spesso dal Framework con cui si sviluppa (ad esempio in MS .Net sono stati forniti vari componenti di questo tipo).
Si chiamano normalmente ORM e praticamente converte una struttura dati di tipo relazionale in una struttura ad oggetti utilizzabile dal programmatore, senza conoscere il linguaggio di accesso ai dati ed avendo risolte tutte le regole di accesso, blocco e sicurezza dei dati.

In informatica l’Object-Relational Mapping (ORM) è una tecnica di programmazione che favorisce l’integrazione di sistemi software aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS.

Il problema che mi si è verificato spesso con questi strati di software, e che spesso nascono e muoiono nel giro di poco tempo poichè legati a tecnologie che diventano obsolete in pochissimo tempo. Avevo provato, per esempio Silverlight di Microsoft nella speranza di una tecnologia che agevolasse lo sviluppo su web, e questo usava Entity Framework, poi è nato LINQ to SQL, ed altri ancora. Per una lista dei principali ORM in commercio o gratuiti vedere questa lista.
Per chi sviluppa e vende software, occorrono certezze e software che duri nel tempo.
Per questa ed altre ragioni, ho creato io un piccolo generatore di ORM personalizzato, che gestisse la creazione di oggetti, la creazioni di funzionalità compatibili con quelle utilizzate con software più vecchi, che creasse in automatico anche funzioni di un web service e che gestisse transazioni e blocchi secondo i miei dettami.
Con questo programma ho creato lo strato di Accesso ai dati (Data Access Layer), che permette di creare in pochi secondi una struttura ad oggetti e una serie di metodi per le principali funzioni di accesso e memorizzazione dei dati.

Con questo programma, puntando ad un server SQL, posso vedere quali databases ci sono, e selezionare con un doppio clic da quale voglio creare le classi per la gestione dei dati.

Dopo appriranno le Tabelle da cui sarà possibile creare le classi e le Stored Procedures che verranno usate da quest’ultime.
Come si vede, viene anche richiesto il tipo di Concorrenza da utilizzare (per SQL Server va bene quella ottimistica, poichè il blocco all’accesso viene garantito dalla transazione).
Questo programmino l’ho duplicato anche per SQLLite e per creare uno strato di accesso ai dati per applicativi su Android, in questo caso le funzionalità erano meno sofisticate e la gestione della Concorrenza veniva suggerita quella Pessimistica, avendo questo Database una gesione delle transazioni più blanda e poichè girando su un device tipicamente individuale, non ci sono necessità di gestione della concorrenza con altri devices.

Una volta creato questo strato software, occorre implementare gli altri due strati, quello della UI (Interfaccia Utente) e quella della BL (Business Layer).
Queste due interfacce spesso si incrociano nello sviluppo, poichè essenzialmente costruendo l’Interfaccia Utente si comincerà a costruire anche lo strato delle funzioni della BL.
Quando invece, si comincia a sviluppare un grosso componente dell’applicativo, occorre realizzare prima le funzioni di base sulla BL.

In informatica l’espressione logica di business (in inglese business logic) si riferisce a tutta quella logica applicativa che rende operativa un’applicazione cioè la parte o nucleo (core) di elaborazione. Con tale nome ci si riferisce quindi all’algoritmica che gestisce lo scambio di informazioni tra una sorgente dati (generalmente una base dati) deputata gestione della persistenza dei dati stessi da una parte e l’interfaccia utente attraverso la logica di presentazione e le elaborazioni intermedie sui dati estratti dall’altra.

Per esempio nell’applicativo Bolero@web, per creare la Gestione della Contabilità Ordinaria, ho dovuto creare una serie di oggetti per gestire le Registrazioni Contabili.
Questa collezione di oggetti sono interconnessi tra loro in maniera gerarchica, ed ognuna carica, salva o elimina i dati.
Con una struttura di oggetti fatta così a partire dal primo oggetto, se questo chiede il caricamento, a cascata tutti gli oggetti sottostanti chiederanno il caricamento dei propri dati.
La stessa cosa accade nel caso di un salvataggio dei dati dell’oggetto, a cascata ogni oggetto dipendente salverà la propria porzione dei dati, e così pure per la eliminazione.
Con una struttura ad oggetti così organizzata è molto facile caricare, inserire o correggere dei movimenti contabili anche molto complessi.
Oltretutto con una struttura così ben definita e suddivisa, è anche facile testare individualmente i singoli oggetti e verificarne il funzionamento corretto.
Per i programmatori basterà caricare gli oggetti e poi lanciare il metodi di salvataggio per inserire i movimenti, mentre per la correzione basterà passare l’ID del Movimento per avere la struttura caricata da correggere ed una volta modificata basterà ripetere il comando di salvataggio.

Quello illustrato sopra è un esempio di come creare uno strato software per interfacciare un programma con i dati, realizzando oggetti utilizzabili da tutta la procedura.

Lo strato più visibile e più apprezzato è quello dell’Interfaccia Utente, come l’utente interagisce con il programma.

L’interfaccia utente, anche conosciuta come UI (dall’inglese User Interface), è ciò che si frappone tra una macchina e un utente, consentendo l’interazione tra i due. In generale può riferirsi a macchina di qualsiasi natura, tuttavia l’accezione più nota è in ambito informatico.

E’ la parte che può definire il successo o il fallimento di un programma, poichè la facilità di utilizzo, la semplicità dei comandi e l’aspetto grafico sono quelli che un utente giudicherà maggiormente, spesso ignorando tutto il resto che è nascosto dietro la facciata.
E’ normale questo, poichè spesso un utilizzatore non può immaginare cosa si nasconda anche solo dietro una piccola applicazione.
Per questa ragione occorre creare interfacce pulite, semplici, di facile utilizzo e con logiche coerenti.
Occorre stabilire le regole comuni a tutti i programmi, poichè non c’è cosa peggiore di una procedura con interfacce diverse a seconda di chi ha realizzato il programma.

I punti principali da mettere a fuoco sono :

• Come si possono selezionare i vari programmi (Menu, Barre Navigazione, ecc.).
• Dove sono i comandi principali di ogni programma (Bottoni, Toolbar, Link, ecc.).
• In che maniera sono mostrate le liste dei dati (Liste, Griglie, Repeater, ecc.).
• Usiamo anche le finestre o solo pagine.
• Schemi di colore, stili e temi.
• Dimensioni e capacità adattativa (Framework adattativo come Bootstrap, Telerik Page Layout, Foundation ecc.).

Nel mio caso ho fatto queste scelte :

• Uso il menu per richiamare i programmi.
• Uso la toolbar in ogni programma.
• Uso le griglie per visualizzare i dati listati.
• Uso anche finestre per alcuni input.
• Uso skin di Telerik e impostazioni fatte con il foglio di stile e con Bootstrap.
• Uso Bootstrap come framework adattativo.

Questi gli esempi di interfaccia presi dall’applicativo Bolero@web.

Questo un altro dettaglio dell’interfaccia.

La scelta di queste caratteristiche deve essere fatta in maniera univoca affinchè tutti i programmi abbiano la stessa interfaccia e le funzioni sempre coerenti tra loro.
L’aspetto dei programmi deve essere uguale in tutte le parti dell’applicativo altrimenti l’utente potrebbe trovarsi in difficoltà.
Invece trovare le stesse funzionalità e gli stessi comandi permette di usare senza problemi qualsiasi programma dell’applicativo.

Occorre spendere molto tempo per queste caratteristiche, ma alla fine un programma viene giudicato soprattutto per la facilità d’uso e l’aspetto generale.
A me piace molto avere interfacce pulite, chiare e lineari, che esprimano eleganza e cura dei particolari.
La mia raccomandazione è di pensare molto all’aspetto che avrà il programma e poi di conseguenza tutto il resto.