|
Object
Oriented
L'approccio di design che sta
alla base delle architetture a componenti odierne è object oriented. Ciò
non significa che tutti i componenti debbano essere costruiti con linguaggi
object oriented (altrimenti non sarebbe possibile riutilizzare, come componenti,
programmi e transazioni legacy), ma che i prìncipi generali della progettazione
di applicazioni a componenti sono basati sull'orientamento agli oggetti.
Ma perché le architetture a
componenti sono basate su prìncipi di progettazione object oriented?
Una diversa (e migliore)
organizzazione del software
L'attenzione e la progressiva
diffusione dell'approccio object oriented sono legate al passaggio (avvenuto,
all'incirca, nel decennio 1980-1990) dalle precedenti architetture monopiattaforma
alle architetture distribuite, multipiattaforma. Questo cambiamento architetturale
si è portato dietro alcune questioni concrete da risolvere: come distribuire
i dati e le funzioni, che costituivano le vecchie applicazioni monolitiche,
su una pluralità di processori cooperanti? Secondo quale logica? Come
far colloquiare tra loro i diversi "pezzi applicativi"?
L'object oriented ha fornito
a queste domande delle risposte innovative ed adeguate dal punto di vista
tecnico, e soprattutto dal punto di vista dell'organizzazione del software.
Un'applicazione ad oggetti
è costituita da un insieme di moduli software logicamente indipendenti,
le classi, che incapsulano dati ed operazioni sui dati (risolvendo la
distinzione tradizionale tra dati e funzioni), e che interagiscono tra
loro tramite scambi di messaggi.
Rispetto ai moduli software
tradizionali, le classi presentano alcuni vantaggi decisivi, sotto il
profilo tecnico-organizzativo
- Elevata coesione interna,
coupling limitato verso l'esterno. Ogni classe è un componente estremamente
coeso, che gestisce un insieme di dati omogenei e le operazioni che
accedono a tali dati , e se necessario li modificano. Vantaggi:
- manutenibilità - le
modifiche sui dati sono normalmente limitate all'ambito omogeneo
della classe che li definisce, poiché i dati sono accessibili solo
alle operazioni interne alle classi
- riusabilità - la classe
fornisce tutte le operazioni significative per l'oggetto business,
utilizzabili in contesti eterogenei
- distribuibilità - la
classe è un elemento ideale per la distribuibilità, grazie alla
sua coesione ed al sufficiente disaccoppiamento rispetto ad altre
classi; nei casi in cui sia opportuno un livello di accorpamento
maggiore, più classi accoppiate tra loro possono essere ricomprese
in un unico componente distribuibile.
- Separazione rigorosa
di interfaccia ed implementazione. Le richieste (messaggi) indirizzabili
ad una classe sono definite esplicitamente (nome messaggio, parametri
di input e di output): l'interfaccia della classe è costituita, precisamente,
dall'insieme dei messaggi che un qualsiasi chiamante (client) può indirizzarle.
L'implementazione della classe è invece inaccessibile ai client. Vantaggi:
- manutenibilità - ogni
variazione all'implementazione di una classe non ha impatto sui
client, se non si verificano variazioni a livello dell'interfaccia;
è possibile sostituire completamente l'implementazione mantenendo
la medesima interfaccia, senza impatti sui client.
- distribuibilità - le
comunicazioni tra le classi avvengono esclusivamente tramite messaggi,
indirizzabili sia in locale che in remoto.
- Polimorfismo. Classi
diverse possono rispondere al medesimo messaggio, ciascuna in modo appropriato.
Il client non ha necessità di conoscere la classe precisa a cui appartiene
l'oggetto su cui sta lavorando, ma può inviare un messaggio generico
la cui risposta dipenderà dalla classe a cui l'oggetto appartiene. Vantaggi:
- riduzione della complessità
- la logica del client risulta semplificata, in quanto viene eliminata
gran parte della logica condizionale legata al trattamento di oggetti
di tipologia diversa
- manutenibilità - le
modifiche ai comportamenti specifici, i quali implementano nelle
diverse classi il modo specifico di rispondere ad un messaggio generico,
sono localizzate nell'ambito delle singole classi, e non devono
essere conosciute dai client.
- Ereditarietà. E'
possibile specializzare una classe esistente, ereditandone attributi
e comportamenti nella nuova classe, ed aggiungendo solo attributi ed
operazioni specifici per la nuova tipologia da gestire. Vantaggi:
- riusabilità - l'ereditarietà
consente di distinguere in modo rigoroso gli aspetti comuni a più
tipologie di oggetti da quelli specifici ad una tipologia particolare,
riducendo il carico di programmazione e al tempo stesso garantendo
una migliore organizzazione del codice
- manutenibilità - le
modifiche ad attributi ed operazioni comuni a più sottoclassi vengono
localizzati al livello della sola superclasse, con una riduzione
del carico di manutenzione.
Queste caratteristiche dell'approccio
object oriented, innovative sul piano tecnico, hanno favorito la progressiva
diffusione dei linguaggi OO in tutti i domini applicativi e nelle realtà
che richiedono volumi di dati e processi elevati.
In particolare, l'approccio
OO è indicato, come dimostra la sua progressiva diffusione nelle grandi
organizzazioni, in tutte le situazioni applicative in cui si manifestino
esigenze di:
- performance elevate (es.
real-time)
- architetture distribuite
(es. client-server, web)
- scalabilità delle applicazioni
- rilascio in tempi rapidi
di nuovi prodotti e servizi
- forte produttività dello
sviluppo e della manutenzione
- riusabilità
- incapsulamento di componenti
legacy
Alcuni tra i vantaggi dell'approccio
object oriented, comunque, possono essere conseguiti anche adottando tale
approccio solo a livello di analisi e design, senza necessariamente ricorrere
a linguaggi OO per la programmazione.
In particolare, analisi e design
OO comportano comunque una migliore organizzazione dell'applicazione,
in quanto le classi costituiscono elementi coesi al loro interno e tra
loro disaccoppiati. Ciò garantisce una migliore manutenibilità, riusabilità
e distribuibilità anche quando la realizzazione delle classi "di analisi"
avvenga utilizzando tecnologie non OO.
La transizione all'object
oriented, per chi non l'ha ancora effettuata, è inevitabile
La superiorità dell'approccio,
sotto il profilo tecnico, rispetto alle modalità di sviluppo tradizionali,
ha avuto conseguenze significative:
- le tecnologie di sviluppo
(ambienti di programmazione visuale, strumenti per l'analisi e il design,
linguaggi) che si sono rese disponibili a partire dagli anni '90 sono
tutte orientate agli oggetti
- e tecnologie di sviluppo
tradizionali (DBMS, TP Monitor), per sopravvivere in un contesto di
architetture distribuite, hanno dovuto aprirsi verso il mondo ad oggetti
·
- il mondo Internet, dal punto
di vista tecnico, è rigorosamente OO ·
- le organizzazioni che hanno
necessità di adeguare rapidamente i sistemi a nuove esigenze di business
adottano l'approccio OO per velocizzare lo sviluppo e la manutenzione
E' solo questione di tempi
e di modi.
Tempi della transizione
La transizione all'object oriented
è costosa, in termini di tempo necessario per rendere il personale di
sviluppo padrone del nuovo approccio (apprendimento linguaggi, e tecniche
per l'analisi ed il design). Da parte delle grandi organizzazioni, la
transizione è iniziata nella prima metà degli anni '90, e sta tuttora
proseguendo, con la progressiva adozione di metodi e tecnologie di sviluppo
da parte di nuove aziende.
Data la superiorità tecnica
dell'approccio OO, che porta a risultati migliori in termini di produttività
dello sviluppo software, e quindi di velocità nel rilascio di nuovi prodotti
e servizi, o nell'adeguamento di quelli esistenti a nuove esigenze, il
momento in cui inizia la transizione può avere conseguenze in termini
di competitività di business. Per chi rimane ancorato ad un approccio
di sviluppo tradizionale, la minore produttività nello sviluppo può infatti
provocare difficoltà nel competere con aziende più tempestive nel fornire
nuovi prodotti e servizi su nuovi fronti e nuovi canali.
Modi della transizione
Non esiste un'unica strada
per la transizione da un approccio di sviluppo tradizionale ad uno object
oriented. Se ne possono distinguere due principali, con una serie di tipologie
secondarie.
Transizione subìta
La transizione può avvenire
senza presidio, quasi spontaneamente.
Per alcune specifiche tipologie
di applicazione, in specifiche aree aziendali, in unione con determinate
tecnologie, vengono introdotti metodi e/o tecnologie di tipo object
oriented . I nuovi approcci convivono con quelli tradizionali, senza
che insorgano necessariamente conflitti, ma in modo non coordinato.
Le scelte tecnologiche e
di metodo effettuate dai diversi gruppi possono essere eterogenee. Non
possono essere perseguite opportunità di razionalizzazione ed ottimizzazione
delle scelte .
La formazione del personale
di sviluppo avviene in modo episodico e frammentato. La transizione
subìta, tipicamente, avviene in tempi più diluiti rispetto alla transizione
gestìta. E' probabile che a livello di management la consapevolezza
della transizione sia complessivamente bassa, e comunque molto differenziata,
anche tra persone che ricoprono ruoli analoghi.
Transizione gestìta
La transizione viene pianificata
e concordata ai diversi livelli di management.
Poiché dovrà avvenire comunque
in modo graduale, vengono chiarite le priorità e le milestones necessarie
per effettuarla riducendo al minimo i rischi ed i costi.
L'introduzione dei nuovi
metodi e delle nuove tecnologie avviene in modo graduale e coordinato,
in linea con scelte architetturali ben definite. Lo stesso avviene per
la formazione.
La coesistenza tra applicazioni
tradizionali e componenti costruiti secondo l'approccio OO è presidiata,
e gestita secondo regole di progettazione standardizzate.
|