Object Oriented Technology

La tecnologia ad oggetti sembra ormai passata da uno stadio sperimentale-avanzato all'impiego comune: quasi ogni nuovo progetto viene intrapreso usando un linguaggio che supporta l'OOP, in modo più o meno deciso. La realtà è che solo una minima parte di tali progetti segue realmente il paradigma ad oggetti: realizzare un prodotto con tecnologia object oriented vuol dire molto di più che scrivere il codice usando il C++ o Java. Non meraviglia quindi che ben pochi progetti ottengano i grandi benefici che si associano abitualmente agli oggetti: maggiore riuso, qualità superiore, facilità di estensione e di manutenzione. Il nostro approccio all'utilizzo della tecnologia ad oggetti, basato su anni di esperienza e di approfondimenti, è decisamente pragmatico ma allo stesso tempo fondato su solidi principi di software engineering. Più precisamente, i nostri punti cardinali sono:

Una solida Architettura di Sistema
Lo sviluppo ad oggetti viene spesso caratterizzato come "iterativo". Se nella sua migliore accezione il termine significa "progettazione graduale, seguita da una verifica incrementale della realizzabilità ed efficacia delle soluzioni", è fin troppo comune vedere una sua degenerazione nello stile "prima implementa e poi progetta".
Nessun progetto significativo può mantenere l'integrità concettuale (da cui derivano la futura estendibilità e manutenibilità del prodotto) senza una adeguata progettazione. Progettazione che non riguarda solo le singole parti, ma anche e soprattutto l'architettura complessiva, ovvero i meccanismi e gli schemi attraverso i quali le singole parti dovranno interagire.

Domain-Specific Framework
Molti sviluppatori hanno incontrato sul loro cammino uno dei tanti framework applicativi (es. MFC). Pochi ne sono rimasti soddisfatti, per diverse ragioni. Una di queste è che un framework orizzontale offre molte classi di infrastruttura, ma non può (né deve) comprendere le parti ripetitive che appartengono al proprio dominio applicativo. Chi sviluppa, ad esempio, programmi di automazione industriale, si ritrova spesso a gestire problematiche simili, che tuttavia non sono previste dai framework orizzontali. Lo stesso avviene in ambito bancario, finanziario, medico, e così via: in ogni settore si ritrovano elementi ricorrenti nelle diverse applicazioni.
La soluzione più efficace, in questi casi, è sempre lo sviluppo di un piccolo framework domain-specific. Piccolo, perché non pretende di catturare più di quanto serva realmente. Domain-specific, perché va studiato intorno alle esigenze che le tipologie di progetti affrontati fanno continuamente riemergere.
Eptacom Consulting ha spesso affrontato la progettazione di framework in settori eterogenei, ottenendo sempre risultati di assoluto rilievo nell'abbattimento dei tempi e dei costi di sviluppo applicativo.

Approccio Sistematico
Estendibilità, riusabilità, manutenibilità, eccetera: le grandi promesse della tecnologia ad oggetti, così di rado mantenute. Non basta infatti conoscere i grandi principi ed adottare un linguaggio object oriented o una notazione come UML: occorre l'esperienza e la capacità di trasferire in pratica i migliori insegnamenti della teoria. Per noi progettazione ad oggetti significa innanzitutto SysOOD (Systematic Object Oriented Design), un approccio alla progettazione basato su regole oggettive e tecniche di trasformazione sistematiche. Un approccio che nasce dalla pratica della progettazione, unita ai più solidi fondamenti della teoria e della ricerca. Un approccio che non solo adottiamo in ogni progetto, ma che insegnamo con successo ad altri sviluppatori e progettisti attraverso corsi aziendali ed interventi a conferenze.

Oggetti e Componenti
Componentware sembra essere la nuova buzzword per chi non ha potuto sfruttare l'onda degli oggetti. In realtà, i componenti software propongono un meccanismo di riuso semplificato rispetto agli oggetti (black-box only), che ha un suo ruolo ed una sua rilevanza in situazioni particolari: ad esempio, la necessità di riuso cross-language, di scripting, o di architetture distribuite. Riconoscere le situazioni in cui i componenti sono realmente vantaggiosi rispetto agli oggetti, e sapere applicare al meglio le diverse tecnologie di componentware, richiede nuovamente esperienza: esperienza che solo chi ha realmente padroneggiato il paradigma ad oggetti può offrire.

Hands-On
Non ci limitiamo mai ai soli diagrammi! Siamo sempre pronti a passare all'azione, a discutere la migliore strategia implementativa, a scrivere insieme a voi un prototipo o parti del codice di produzione. La nostra esperienza di programmazione con linguaggi ad oggetti come il C++ non teme decisamente confronti.

Interessati? Parlatene con noi all'indirizzo oot@eptacom.net, o chiamateci allo 019-8160697.