Ogni nuovo viaggio è sempre un mix di scoperte, difficoltà e fallimenti che però ti portano ad una nuova destinazione che, altrimenti, non avresti mai raggiunto.

Così, il mio nuovo viaggio alla scoperta dell’Internet of Things inizia da quello che è il mio know-how nel mondo dell’ingegneria del software e del process & business management, da cui attingo l’approccio inspect-and-adapt, ovvero quello di analizzare e risultati e adattarsi di conseguenza, unitamente all’idea di “esperimento” incentrato sul build-measure-learn.

Quando parliamo di “Internet of Things”, esistono tante definizioni che cercano di spiegarne l’essenza, ma la più concisa, a mio parere è quella di IoT-A: “La rete globale che connette qualsiasi smart object”. Semplice e concisa.

Chiarito cos’è l’IoT (sarà realmente così? J), veniamo alla domanda fondamentale “Ok, giochiamo un po’ con l’IoT, ma da dove iniziamo?” e alle sue specializzazioni:

•  “Quali device acquistare per iniziare?”
• “Quali piattaforme software utilizzare?”

Per il software, essendo legato al mondo Microsoft, la risposta è scontata: vediamo di riutilizzare tutto quanto conosco in ambito .Net, Visual Studio, ecc.. ecc…

Per quanto riguarda l’hardware, invece, si tratta di un punto particolarmente ostico per me, avendolo sempre approcciato come il “contenitore” del software. Per non perdermi tra le decine di offerte, mi affido all’amico Paolo Patierno (MVP in chiave IoT) e, dopo una serie di scambi di opinione, acquisto:

• 1 Netduino 3, ovvero una board Arduino-based ma con a bordo il .Net Framework;
• 1 Raspberry PI 2, su cui proverò ad installare Windows 10 for IoT;
• 1 Microsoft Band, per i dati biometrici.

Per l’MS Band vi consiglio di controllare bene le dimensioni del cinturino. Dopo aver preso la versione “M” (esistono S, M, L), mi sono accordo che era troppo stretto e ho dovuto procedere con il servizio di Amazon.uk (in Italia non è acquistabile) per restituire l’oggetto e fare un nuovo acquisto del modello “L”.

 Iot devices unboxing

Manca ancora qualche sensore, ma questo verrà in seguito.

Per il software, la scelta è ricaduta su Connect the Dots, che mette a disposizione un framework per iniziare a lavorare con device ed Azure in ottica IoT. Per l’Azure IoT Suite bisogna ancora attendere un pochino, così come per soluzioni “scratch”.

Ok, per ora basta scrivere… comincio a rimboccarmi le maniche ;-)

Quando pensiamo all’Architettura di una soluzione Enterprise, di getto immaginiamo il pattern Layer Based, che, a prima vista, ci consente di applicare in modo efficiente il principio di Separation of Concerns, ovvero dell’indipendenza dei moduli e del loro raggruppamento per affinità funzionale. Il tutto consentendoci di approcciare in modo più efficace ad un problema complesso.

Tipica Architettura a Layer

In realtà, questa architettura crea una dipendenza diretta (transitiva) di tutto il sistema dal Repository (Data Layer), trasformando il sistema in una soluzione data-centric. Dalla figura di esempio si vede, inoltre, la dipendenza diretta dai cosiddetti support layer(infrastructure, utility, ecc…), rappresentati in assetto verticale ed utilizzati da tutti i layer orizzontali.

Nonostante questo pattern architetturale sia largamente utilizzato ed apprezzato, possiamo individuare alcuni punti di debolezza non proprio “banali”:

1. Forte dipendenza dall’infrastruttura dati;
2. Dipendenza diretta dai framework di supporto;
3. Al crescere della complessità diventa difficile mantenere la netta separazione dei moduli, individuandone il loro “posizionamento”: spesso si inserisce codice di business all’interno della UI.

Proviamo ora a rappresentare diversamente un’architettura layer-based, in modo da evidenziare esplicitamente quanto appena evidenziati:

Tipica Architettura a Layer (rappresentazione circolare)

In questa nuova conformazione è subito visibile la centralità dei dati e la presenza “invasiva” dei framework di supporto/sviluppo. Ora, la domanda è: perché deve essere così? Perché ci si deve legare a tali strumenti piuttosto che esserne idealmente indipendenti?

Tali questioni non sono, ovviamente, nuove, ed in letteratura esistono quelle che possiamo considerare “evoluzioni” del modello architetturale layer based. In particolare Robert Martin (aka Uncle Bob) e Jeffrey Palermo hanno suggerito due soluzioni, molto simili tra loro: Clean Architecture e Onion Architecture.

Clean Architecture

Onion Architecture

Senza voler entrare nelle specifiche differenze (sostanzialmente poche), è interessante evidenziare come tali architetture siano fortemente basate sul Dependency Inversion Principle (DIP, SOLID):

1. High-level modules should not depend on low-level modules. Both should depend on abstractions;
2. Abstractions should not depend on details. Details should depend on abstractions;

I layer sono concentrici e la dipendenza è dagli anelli più esterni a quelli più interni, centrando il focus sul Dominio Applicativo e sui relativi Servizi annessi, elementi tanto cari ai fautori di DDD. Il legame con il Repository dei Dati o con i Servizi di supporto avviene tramite Dependency Injection, poiché i livelli CORE definiscono solo le Interfacce con cui interagire. Salterà sicuramente all’occhio dei lettori più attenti che UI, Infrastructure, DB e anche TEST sono posizionati sul livello più esterno: si tratta di un elemento di grande rilievo che consente di avere un nucleo applicativo indipendente da quelle che possiamo definire “facility”. Nonostante ciò, però, la divisione del livello esterno in “comparti”, ne garantisce la consistenza ed evita, ad esempio, che un modulo appartenete alla UI possa dialogare direttamente con uno appartenente ai Dati.

A differenza dell’architettura layer-based, ogni cerchio può accedere a tutti i livelli interni, creando quella che viene definita una relazione di dipendenza verso l’interno (verso il Dominio), del tutto voluta, ma non verso elementi di supporto che posso, e sicuramente lo faranno, variare nel tempo ed essere agevolmente sostituiti.

Onion Dependencies

Nel livello Core troviamo una serie di funzionalità di Domino ben delineate, così come riportato nella figura seguente:

Onion "Core"

Se ora proviamo a fare un’operazione simmetrica a quella precedente (passiamo dalla rappresentazione concentrica a quella lineare), una Onion Architecture potrebbe apparire come segue:

Onion Architecture "flat" view

Andiamo ora a fare il punto di quanto si racchiude nel pattern Onion:

• L’Applicazione è creata intorno ad un modello di Dominio indipendente;
• I layer interni definiscono le interfacce, i layer esterni le implementano;
• La direzione della dipendenza è verso il centro;
• Il core del sistema può essere compilato ed eseguito (con opportuni fake se necessario) in modo indipendente dall’infrastruttura.

Come detto, tutto ciò porta ad vere una “vero” decoupling tra i vari layer, favorendo l’aggiornamento/sostituzione di tutti i moduli infrastrutturali e creando una razionalizzazione dei classici progetti “Common/Infrastructure/ecc”.

Aforismi e frasi celebri che ben si adattano al mondo Agile

• "Molto da apprendere ancora tu hai."
• "Un uomo può sempre accordarsi con gli altri... e' molto più difficile che sia d'accordo con se stesso..."
• "Cosi sicuro sei tu. Sempre per te non può essere fatto. Tu non senti ciò che dico!"
• "Fare o Non Fare, non esiste provare!" 

Abbiamo più volte affrontato la questione dei Requisiti Non Funzionali o di Qualità, e affermato la loro fondamentale rilevanza nella definizione dell’Intentional Architecture. Inoltre, abbiamo visto come in Agile sia possibile pensare a delle (Technical) User Story che contemplino gli NFR e come esista una loro congiunzione diretta all’ALM con un occhi particolare a DAD.

A questo punto, cerchiamo di rispondere più in dettaglio ad una semplice domanda che, però, cela una risposta complessa:

            “Come catturo opportunamente gli NFR, in modo sintetico e non ambiguo?”

Una soluzione interessante è quella proposta da Bass, Clements e Kazman in “Software Architecture in Practice”, che propone di definire uno specifico attributo di qualità (o meglio di dettagliare quali aspetti di esso afferiscono al contesto/progetto specifico) attraverso un Quality Attribute Scenario.

Quality Attribute Scenario

Nel dettaglio, uno tale scenario è esplicitato attraverso 6 elementi:

• Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
• Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
• Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
• Environment (Contesto), il contesto in cui si verifica lo stimolo;
• Response (Risposta), come il sistema risponde allo stimolo;
• Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

Vediamo un esempio concreto di scenario generale afferente alla requisito di Availability (Disponibilità)

Quality Attribute Scenario for Availability

In cui troviamo:

Personalmente ritengo che questo approccio permetta di definire dettagliatamente gli NFR, scrollandogli di dosso quella aleatorietà che spesso gli si associa con affermazioni del tipo “Il Sistema deve essere sicuro!”, prendendo, eventualmente, come riferimento gli attributi esplicitati nello standard ISO 9126 (ISO/IEC 25000 dal 2005).

Una volta definiti gli scenari è possibile passare alla stesura di una prima ipotesi di Intentional Architecture, utilizzando Tattiche e Pattern Architetturali per abbracciare l’insieme degli NFR. Inoltre è possibile definire le (Technical) User Story per il ciclo di sviluppo, o un'altra formalizzazione delle specifiche dipendente dalla metodologia scelta.

La cosa su cui ritengo untile spendere un ulteriore passaggio è che tale approccio si applica sia agli attributi che afferiscono ai componenti e alle loro iterazioni (component-and-connector) sia agli attributi relativi alla definizione statica dell’architettura (modules). Quest’ultimo aspetto non è immediato come quello che più afferisce al funzionamento del sistema, ma è altrettanto fondamentale. Un esempio per tutti è la Modifiability, alias l’attitudine del sistema ad essere modifica e/o adattato.

Modifiability Scenario relativo al cambio della UI

Come si vede dalla figura precedente, l’Environment è “Design Time” e quindi implica uno scenario che afferisce alla specifica fase di definizione della struttura del sistema.