Naked objects
I Naked objects (oggetti nudi) costituiscono un pattern architetturale (un modello architetturale) utilizzato in ingegneria del software.
Definizione[modifica | modifica wikitesto]
Il modello dei naked objects è definito tramite tre principi:
1. Tutta la logica di funzionamento deve essere incapsulata all'interno degli oggetti di dominio. Questo principio non è di esclusiva pertinenza dei naked objects: esso è semplicemente un rafforzamento delle regole dell'incapsulamento.
2. L'interfaccia utente deve essere una rappresentazione diretta degli oggetti di dominio, in cui tutte le azioni effettuate dall'utente consistono esplicitamente nel creare, o nel richiamare, oggetti di dominio, e/o invocare metodi su questi oggetti. Anche questo principio non appartiene solo ai naked objects: è solo una interpretazione più stringente di una interfaccia utente orientata agli oggetti (object-oriented user interface - OOUI).
L'idea originale nel modello dei naked objects risiede nella combinazione dei due principi precedenti, per formare il terzo principio:
3. L'interfaccia utente dovrebbe essere creata automaticamente al 100% dalla definizione degli oggetti di dominio. Ciò può essere realizzato usando numerose tecnologie diverse, inclusa la generazione automatica di codice sorgente; implementazioni di questo modello finora hanno privilegiato la tecnologia della riflessione.
Il modello dei naked objects fu descritto per la prima volta con metodo formale nella tesi di laurea di Richard Pawson [1] che comprende una approfondita investigazione di vari spunti antecedenti e ispirazioni per arrivare al modello attuale, includendo per esempio l'interfaccia utente del programma "Morphic".
I naked objects hanno come tipico antagonista l'architettura "modello-vista-controllore" (model-view-controller). Comunque, la versione pubblicata nella tesi di Pawson (vedi Note) contiene una prefazione di Trygve Reenskaug, il quale formulò per primo l'architettura "modello-vista-controllore", nella quale suggerisce come i naked objects risultano più vicini alla suddetta architettura, che non molte altre interpretazioni e implementazioni successive.
Benefici[modifica | modifica wikitesto]
La tesi di Pawson descrive quattro benefici del modello:
- Un ciclo di sviluppo più rapido, perché ci sono meno strati di software da realizzare. In una progettazione più tradizionale, lo sviluppo deve definire e implementare tre o più strati separati: lo strato degli oggetti di dominio, lo strato di presentazione, e gli script del processo o sotto-programma che collega i due. Se il modello naked objects viene combinato con la mappatura relazionale degli oggetti, o un database degli oggetti, allora è addirittura possibile creare tutti gli strati del sistema partendo solo dagli oggetti di dominio; comunque, questa caratteristica non è in sé facente parte del modello. La tesi contiene uno studio su un caso reale, confrontando due diverse implementazioni della stessa applicazione: una basata su una implementazione tradizionale a quattro strati, l'altra sui naked objects.
- Una maggiore agilità, in riferimento alla facilità con cui un'applicazione può essere modificata per adattarsi a futuri cambiamenti nel funzionamento richiesto. In parte questo nasce dalla riduzione del numero di strati già sviluppati che devono essere mantenuti sincronizzati. Comunque, si pretende anche una corrispondenza diretta tra la presentazione all'utente e il modello del dominio, e ciò rafforza la necessità di una modellazione di più alta qualità, da cui deriva un miglioramento dell'agilità.
- Uno stile più autoritario dell'interfaccia utente. Questo beneficio è effettivamente attribuibile all'interfaccia utente risultante dal modello, piuttosto che al concetto stesso dei naked objects, sebbene sia un dato di fatto che questi ultimi rendono più facile la concezione e l'implementazione dell'interfaccia utente.
- Analisi più facile dei requisiti. Questo fatto si spiega perché, con il modello dei naked objects, gli oggetti di dominio formano un linguaggio comune tra utenti e sviluppatori e questo facilita il processo di discussione dei requisiti, in quanto non ci sono ulteriori rappresentazioni su cui discutere. Mettendo ciò in combinazione con il ciclo di sviluppo più rapido, diventa possibile realizzare, praticamente in tempo reale, dei prototipi funzionanti dell'applicazione.
Limitazioni[modifica | modifica wikitesto]
L'interfaccia utente auto-generata è potenzialmente adatta per applicazioni a sé stanti, ma non per applicazioni transienti o di servizio.
Ambienti di sviluppo Software[modifica | modifica wikitesto]
Sono attualmente disponibili vari ambienti di sviluppo e framework che implementano il modello dei naked objects:
- Domain Object Explorer [collegamento interrotto], su doe.dev.java.net.
- dotObjects, su codeplex.com.
- JMatter, su jmatter.org. URL consultato il 26 aprile 2019 (archiviato dall'url originale il 3 febbraio 2014).
- Naked Objects for Java, su nakedobjects.org.
- Naked Objects for .NET, su nakedobjects.net.
- Sanssouci, su freecode.com.
- Trails, su trailsframework.org.
- TrueView for .NET, su evolving-software.co.uk. URL consultato il 6 aprile 2010 (archiviato dall'url originale il 4 maggio 2010).
- Typical Objects for C++, su typicsoft.com. URL consultato il 6 aprile 2010 (archiviato dall'url originale il 17 luglio 2011).
- Lablz - Data objects as Web Applications, su lablz.com. URL consultato il 6 aprile 2010 (archiviato dall'url originale il 13 maggio 2010).
Esperienze pratiche[modifica | modifica wikitesto]
Il Dipartimento per gli Affari Sociali e Familiari dell'Irlanda ha realizzato una suite di applicazioni di alto livello utilizzando il modello naked objects. Come attività che fa parte del Programma per la Modernizzazione della Fornitura del Servizio, il Dipartimento ha progettato una nuova architettura di alto livello sia per i suoi nuovi obiettivi di business, che per ottenere una maggiore agilità nel servizio valutato nel lungo termine. Il modello naked objects costituisce un elemento chiave in questa architettura. [2]. Nel novembre del 2002, il Dipartimento ha messo in servizio una nuova applicazione che rimpiazza il suo sistema preesistente per l'amministrazione dei sussidi ai bambini. Si ritiene che questa sia la prima applicazione che fa uso del modello naked objects, per la prima volta nel mondo. L'esperienza del Dipartimento nella realizzazione di questa prima applicazione, comprese le impressioni d'uso degli utenti a questa nuova interfaccia utente, è documentata estensivamente nella tesi di Pawson. [3].
Uno degli aspetti che più colpiscono dell'esperienza del Dipartimento è stato il modo in cui la tecnica naked objects ha permesso il riuso dei componenti in modo molto spinto. Una volta che un oggetto di dominio, come ad esempio l'oggetto "Cliente", è stato definito per una applicazione, esso è stato poi rapidamente adattato con una minima rimaneggiatura e ampliamento, per essere riusato in altre situazioni. Questo suggerisce che tale approccio potrebbe diventare privilegiato nell'ambito governativo, dove il riuso è visto come una potente tecnica per scomporre in parti più semplici gli esistenti sistemi di gestione monolitici e specializzati. La politica inglese dell'"Amministrazione in Trasformazione" è particolarmente incline a vedere il riuso come un'esigenza obbligatoria dei nuovi sistemi di amministrazione pubblica, sia sfruttando altri componenti del sistema amministrativo, che realizzandone di nuovi e mettendoli poi a disposizione. Il riutilizzo è spesso visto in termini di servizi offerti, ma l'approccio a oggetti può essere altrettanto efficace.
La fase iniziale messa in opera dal Dipartimento, denominata "Architettura Naked Objects", fu affidata su contratto a un ente esterno [4], ma in seguito l'architettura fu riveduta sfruttando l'ambiente open source Naked Objects, che attualmente costituisce le basi per lo sviluppo delle applicazioni future, come confermato dalla richiesta di appalti per un programma quadriennale di ulteriori applicazioni da costruire usando i naked objects [5].
Critiche[modifica | modifica wikitesto]
Il modello naked objects ha sollevato una discreta quantità di critiche fin dalla prima dimostrazione pubblica dell'idea, avvenuta alla conferenza OOPSLA 2001, con la denominazione di Technologie Intriganti. Le critiche si sono di solito concentrate su una di queste tre aree:
- La validità del concentrarsi a incapsulare tutta la logica di funzionamento all'interno degli oggetti di dominio.
Nella letteratura accademica della programmazione orientata agli oggetti, e della progettazione domain-driven, si possono trovare argomentazioni sia pro che contro questa idea.
- L'applicabilità reale di interfacce utente orientate agli oggetti[6].
- L'usabilità di interfacce utente così generiche.
Nessuna di queste critiche colpisce solamente i naked objects, ma il fatto che i naked objects combinano tutte e tre queste problematiche, li rende più esposti.
Relazioni con altre idee[modifica | modifica wikitesto]
Il modello naked objects ha rilevanza verso parecchie altre discipline e/o correnti di pensiero, tra cui:
- Meccanismi di memorizzazione dell'oggetto
- la mappatura relazionale di oggetti, i database di oggetti, e la persistenza di oggetti sono tutti interessati a eliminare la necessità di scrivere uno strato software tradizionale di accesso ai dati, sottostante agli oggetti di dominio. Questi modelli sono complementari e potenzialmente sinergici con il modello naked objects, che a sua volta è interessato a eliminare la necessità di scrivere degli strati software soprastanti gli oggetti di dominio.
- Sviluppo agile del software
- i naked objects sono compatibili con gli orientamenti che tendono a metodiche di sviluppo agile, in molti modi diversi, ma specialmente nello sviluppo iterativo di affinamento.
L'esperienza del Dipartimento irlandese, descritto sopra, è anche stata probabilmente la più vasta applicazione di tecniche di sviluppo agile di software, in un'organizzazione del settore pubblico, a livello mondiale. [7].
- Progettazione domain-driven
- questo tipo di progettazione si rifà all'idea che il modello, di un dominio o di un oggetto, in evoluzione, dovrebbe essere usato come un meccanismo che aiuta a esplorare i requisiti, piuttosto che succeda il contrario. Il fatto che un sistema con naked objects impone una corrispondenza diretta tra l'interfaccia utente e il modello del dominio, rende più semplice il tentativo di una progettazione domain-driven, e rende i benefici più evidenti.[8]
- Architettura model-driven (Model-driven architecture - MDA)
- Sebbene i naked objects non sono conformi alle stringenti definizioni MDA, essi condividono molti degli stessi obiettivi. Dan Haywood ha spiegato che i naked objects costituiscono un approccio più efficace per raggiungere questi obiettivi[9].
Note[modifica | modifica wikitesto]
- ^ Pawson, R., Naked Objects, Ph.D Thesis, 2004, Trinity College, Dublin, Ireland pdf version Archiviato il 27 giugno 2014 in Internet Archive.
- ^ Department of Social and Family Affairs - Guide to the Functions & Records of the Department, DSFA website - Freedom Of Information Archiviato il 5 luglio 2008 in Internet Archive.
- ^ Pawson, R., Naked Objects, Ph.D Thesis, 2004, Trinity College, Dublin, Ireland pdf version Archiviato il 15 giugno 2006 in Internet Archive.
- ^ Fujitsu, Case Study: The Department of Social and Family Affairs Fujitsu website Archiviato il 29 novembre 2007 in Internet Archive.
- ^ Department of Social & Family Affairs, The ongoing development of the Department's Service Delivery Modernisation programme, 2007, e-tenders website[collegamento interrotto]
- ^ Larry Constantine: The Emperor Has No Clothes: Naked Objects Meet the Interface
- ^ Pawson, R and Wade, V, Agile Development using Naked Objects, Extreme Programming and Agile Processes in Software Engineering 4th International Conference, XP 2003 Genova, Italy, Proceedings[collegamento interrotto]
- ^ Haywood, D., Domain-Driven Design using Naked Objects Archiviato il 21 settembre 2018 in Internet Archive., 2009, Pragmatic Programmers
- ^ Haywood, D (2004) MDA: Nice idea, shame about the...
