Tecnologie di implementazione per i pattern architetturali

Tecnologie di implementazione per i pattern architetturali

Tecnologie di implementazione per i pattern architetturali

Per tecnologia di implementazione intendiamo non solo il linguaggio di programmazione ma anche tutti i requisiti ad esso legati. Se si sceglie di usare un particolare linguaggio, si dovrà adattare la struttura del sistema, le specifiche nel codice, le piattaforme da utilizzare e tutto il contesto che c’è dietro le tecnologie di implementazione. Prima di parlare di tecnologie diamo una definizione di componente.

Cosa è un componente?

Per dare questa definizione,entriamo nel merito del modello di processo Component Based, che non è solo un modello di processo perché può essere usato trasversalmente agli altri.E’ un processo di definizione, implementazione o integrazione di componenti debolmente accoppiati, ossia che abbiano lasca connessione tra loro. Il Component Based Software Engineering nasce dal concetto di modularità e riutilizzo, e si basa su componenti indipendenti e standardizzate, sul middleware e sul processo di sviluppo.

Secondo l’OMG un componente è una parte modulare, utilizzabile e sostituibile di un sistema che comprende l’implementazione ed espone una serie di interfacce. Sostanzialmente un componente è un elemento costitutivo del software.

Un componente deve essere standardizzato, indipendente, componibile (si deve poter integrare nelle interfacce pubbliche del sistema), consegnabile e documentato.

Comunicazione tra processi e IPC

Se abbiamo un sistema basato su componenti abbiamo un middleware, che è lo strato che troviamo tra il software applicativo e il sistema operativo, e implementa un meccanismo di comunicazione tra processi.

La comunicazione tra processi è generalmente nota come IPC (Inter Processing Communication). Essa avviene mediante diversi meccanismi e schemi a diversi livelli. Può avvenire o a basso livello, o a livello di linguaggio di implementazione, o a livello applicativo o mediante software. A seconda di dove avviene la comunicazione, cambieranno le primitive e i meccanismi di comunicazione. A diversi livelli possiamo utilizzare il meccanismo di Pipe (Pipe and Filter),  o il  socket, che è un canale di comunicazione a livello più basso di quello applicativo, oppure mediante il memory mapped file,quindi a livello hardware, oppure mediante chiamata a procedura remota (RPC), a livello applicativo e sempre a questo livello può essere utilizzato il meccanismo di scambio di messaggio.

In base alla modalità secondo cui avviene IPC possiamo caratterizzare il middleware secondo tipologie diverse:

  • Remote Procedure Control (RPC), quando abbiamo architetture Client- Server;
  • Remote data access, simili a RPC, tipicamente utilizzate per accedere a basi di dati (database);
  • Message Oriented middleware (MOM);
  • Transaction processing monitor (TP- Monitor);
  • Distributed object, in cui l’invocazione dell’oggetto avviene tramite il broker.

I modelli di componenti possono essere standardizzati, infatti a parte i nostri componenti, ci sono componenti standard che vengono acquistati, integrati nell’applicazione e che sono ad esempio quelli del formato Microft.net, nel formato Corba, o nel formato Java beans.

Tra i componenti Microsoft troviamo i seguenti:

  • Com, Component Object Model;
  • Dcom, Distributed Component Object Model;
  • Com+;
  • Soap, protocollo a livello ancora più alto nella comunicazione tra applicazioni ed è basato su XML, ossia un linguaggio che ci permette di formattare dei dati, e creare dele strutture nell’ambito dei dati. Linguaggi di mark-up;
  • .Net, componente più standardizzato e moderno per eterogeneità di linguaggio.

Lo standard CORBA

L’OMG (Object management group) definisce lo standard di oggetti per esempio CORBA per oggetti distribuiti.

Corba è la tecnologia per implementare architetture a oggetti distribuiti più diffusa,si basa sul broker e garantisce eterogeneità di linguaggi e di piattaforme, ossia posso realizzare applicazione in cui i vari oggetti sono realizzati con linguaggi diversi e funzionano su piattaforme diverse, il middleware Corba permette la comunicazione tra questi oggetti eterogenei e realizzare l’applicazione distribuita in cui i componenti sono tutti allo stesso livello.

Lo standard SUN

L’altro standard é SUN, infatti se standardizziamo i componenti secondo questo meccanismo, la comunicazione avviene tramite RMI( Remote method information), ossia gli oggetti possono essere eseguiti su macchine virtuali diverse e comunicare mediante chiamate a metodi remoti. Gli oggetti si chiamano Java beans, o enterprise java beans se rientrano in una fascia di componenti più complessi.

Applicazioni Web e pattern

Se invece siamo in un contesto Web e vogliamo realizzare applicazioni Client- server, dobbiamo partire dalla definizione di applicazione web, ossia “un sistema che permette ai propri utenti di eseguire la logica di business con un browser” (Conallen, 2000).

In un’applicazione web troviamo una logica di business che può risiedere o sul client o sul server, un browser che è indispensabile per interpretare parte della logica che verrà eseguita sul Client, e pagine web che possono essere statiche o dinamiche. L’application server è il server applicativo che monitora lo stato dell’applicazione, importante per tenere traccia delle operazioni effettuate, dello stato degli utenti e così via. Ad esempio come monitorare mediante i cookie, rappresenta lo stato dell’utente collegato, e ci permette di avere traccia delle operazioni svolte dai diversi Client. Questo è molto utile soprattutto se il numero di utenti è molto elevato. Possiamo rendere dinamica una pagina web tramite uno script, ossia un programma interpretato dal browser.

L’interprete interpreta ed esegue direttamente istruzione per istruzione, invece il compilatore è un traduttore che dato un programma sorgente genera un programma eseguibile. Sono due fasi distinte, solo che in determinati casi, come in Java, si ha un linguaggio che per metà è interpretato e per metà viene compilato.

Quando invece abbiamo la pagina server, possiamo utilizzare diverse tecnologie come le java server pages o le servlet se utilizziamo una tecnologia Java.

Abbiamo visto che a livello progettuale il modello logico di un applicazione su un architettura client server, si realizza con il pattern MVC (Model view Control), simile a questo pattern è il pattern BCE, Boundary control entità, e trova anche riferimento nell’UML. Lo scopo è individuare i confini del sistema, caratterizzare i dati, progettare e implementare la logica di controllo dell’applicazione stessa.

Il pattern trova una sua diretta configurazione nell’UML perché è possibile utilizzare gli stereotipi delle classi stesse: <<Boundary>>.

Le classi Boundary

Le classi Boundary sono classi di interfaccia tra l’attore e il sistema, e lo scopo è quello di isolare il sistema dai cambiamenti che avvengono nell’ambiente esterno e di interfacciare le classi con altri sistemi. Le classi Control sono quelle che si collocano al centro del modello, e quindi nel lato server e gestiscono tutte le operazioni di elaborazione e implementano la logica di controllo delle applicazioni (ad esempio le servlet delle applicazioni Java).sono indipendenti dall’ambiene esterno e non sopravvivono all’interazione.

Infine le classi entità definiscono il modello dei dati, e nascono già in fase di analisi, sono le prime che derivano direttamente dai requisiti. Nelle fasi successive saranno sempre presenti ma saranno affiancate da altre classi (Boundary e Control).

A causa del gap esistente tra il modello dei dati relazionali e il modello dei dati ad oggetto, le classi entità rappresentano la modellazione dei dati nell’ambito però del nostro sistema, e tramite esse avverrà l’accesso dai dati da elaborare che saranno presenti nel database, mediante l’utilizzo dell’ibms o mediante il DAL che implementerà la logica di accesso al database. Eventualmente si può pensare di inglobare parte di questa elaborazione nel livello entità oppure di aggiungere un ulteriore livello che nella formalizzazione del modello BCE si formalizza con una D per cui diventa BCDE, Boundary Control Entity Database ed è l’applicazione di un modello DAL che realizza solo l’implementazione delle transazione e delle query.

Lo schema grafico è il seguente:

Tecnologie di implementazione - Boundary Control Entity Database
Tecnologie di implementazione – Boundary Control Entity Database

 Estendendo l’architettura a tre livelli a una a N-livelli vengono introdotti un livello USER e uno INTEGRATOR, il primo è molto vicino al livello di presentazione, mentre nel secondo si può prevedere l’introduzione  di un broker in modo che si integrino dati provenienti da database diversi, e quindi un ulteriore livello in modo da rendere l’applicazione mappabile sull’architettura a tre livelli.

Ingegneria del software per le Applicazioni Enterprise

Le applicazioni ENTERPRISE, sono una categoria di applicazioni il cui nome si riferisce sia alle applicazioni che le tecnologie , e sono riferite ad applicativi in un contesto ampio di grossa organizzazione, utilizzate per fornire delle funzionalità di supporto alla logica di business anche per una grossa impresa, al di là del semplice portale che si realizza si può immaginare la stessa struttura però proiettata in un contesto molto più grande e quindi si parlerà di applicazione enterprise. Il meccanismo è lo stesso ma cambia la granuralità e l’ampiezza del contesto, cambiano le tecnologie e anche i modelli architetturali.

Precedente Pattern architetturali con esempi pratici Successivo Panoramica sul processo di sviluppo del software

Lascia un commento

*