Quando si tratta di un buon design OO, mantienilo semplice

Un mio ex studente una volta ha sbottato l'assurda affermazione: "Non posso assolutamente fare design orientato agli oggetti (OO); non ho i soldi!" Indagando ulteriormente, si è scoperto che, nella sua mente, il design OO richiedeva un prodotto chiamato Rational Rose, che all'epoca costava circa 500,00 per posto. Nella sua mente, senza Rational Rose, il design non era possibile. Purtroppo, questo tipo di balderdash è molto diffuso; troppe persone pensano che l'OO sia un processo high-tech che richiede strumenti high-tech. In pratica, gli strumenti dal prezzo esorbitante rimangono inutilizzati sullo scaffale (o sono ampiamente sottoutilizzati).

Con questo in mente, in questo articolo discuto di vari strumenti di progettazione OO, come funzionano e perché penso che non siano utili. Spiego anche come lavoro e cosa si rivela utile (almeno per me; sei il benvenuto a non essere d'accordo).

Gli strumenti non ti guidano attraverso il processo

Ogni progetto OO di successo che ho ideato ha seguito più o meno lo stesso processo:

  • Informazioni sul dominio del problema (contabilità, pianificazione delle lezioni, ecc.)
  • Sviluppa, in stretta consultazione con un utente dal vivo, una dichiarazione del problema che descriva in modo esaustivo il problema dell'utente, nonché eventuali soluzioni a livello di dominio. Questo documento non descrive un programma per computer.
  • Eseguo un'analisi formale del caso d'uso, in cui determino le attività necessarie per risolvere il problema dell'utente, ancora una volta, lavorando a stretto contatto con un utente finale reale. In genere creo un diagramma di attività UML (Unified Modeling Language) per ogni caso d'uso non banale. (UML è una rappresentazione simbolica del software come immagine.)
  • Inizia a costruire il modello dinamico che mostra gli oggetti nel sistema e i messaggi che questi oggetti si inviano l'un l'altro, mentre viene interpretato un caso d'uso particolare. A questo scopo utilizzo un diagramma di sequenza UML .
  • Catturo simultaneamente informazioni utili sul diagramma del modello statico . Nota: non eseguo mai prima il modello statico (diagramma delle classi). Ho buttato via troppi modelli statici che si sono rivelati inutili una volta che ho iniziato a fare il modello dinamico. Non sono più disposto a sprecare il tempo necessario per realizzare il modello statico nel vuoto.
  • I passaggi sopra menzionati producono tipicamente due o tre casi d'uso, dopodiché inizio la codifica, correggendo il modello se necessario.
  • Infine, lavoro su un altro caso d'uso come descritto, rifattorizzando il design e il codice come necessario per adattarsi al nuovo caso.

Nessuno degli strumenti di progettazione odierni ti guida in questo processo. Per la maggior parte, sono programmi di disegno troppo costosi che non funzionano particolarmente bene, anche come strumenti di disegno. (Rational Rose, che considero una delle meno capaci del lotto, non supporta nemmeno tutto UML.)

L'ingegneria di andata e ritorno è un processo fondamentalmente difettoso

Non solo questi strumenti non funzionano bene, ma l'unico trucco che questi strumenti eseguono - generare codice - è inutile. Quasi tutti gli strumenti di progettazione OO seguono il concetto di ingegneria di andata e ritorno in cui inizi in uno strumento di progettazione specificando il tuo progetto in UML. Si creano due insiemi essenziali di diagrammi: il modello statico che mostra le classi nel progetto, le loro relazioni tra loro ei metodi che contengono; e il modello dinamico, che è una pila di diagrammi che mostrano gli oggetti nel sistema che eseguono varie attività in fase di esecuzione.

Una volta completato il modello, premi un pulsante magico e lo strumento genera il codice. Tuttavia, il codice generato dallo strumento non è particolarmente valido per due motivi: in primo luogo, in molti strumenti vengono creati gli scheletri per le definizioni di classe, ma i metodi sono semplicemente stub vuoti: il modello dinamico viene ignorato. In secondo luogo, nessuno strumento supporta completamente UML, principalmente perché nessuno può farlo. UML è un linguaggio a sé stante, che incoraggia l'improvvisazione, e gran parte del contenuto effettivo del design è espresso in commenti tipicamente ignorati dallo strumento di progettazione.

Di conseguenza, hackerate il codice generato (la maggior parte dei negozi lo hackera davvero). Nel giro di poche settimane, il codice in genere ha poco o nulla a che fare con il design originale. In effetti, butti via effettivamente il tuo progetto e ricadi nella sindrome WHISKY (perché qualcuno non sta ancora "koding"?). Anni e anni di programmi falliti mi dimostrano che la codifica senza un design aumenta il tempo di sviluppo complessivo di almeno un fattore tre e si traduce in codice molto più aggiornato.

Ora arriva il processo di andata e ritorno: apri lo strumento, premi il pulsante magico e importa il codice, ricostruendo teoricamente il design in modo che rifletta lo stato effettivo del codice. Tuttavia, tale ingegneria inversa non funziona. Gli strumenti in genere creano nuovi diagrammi di classe, ma non aggiornano mai il modello dinamico. Poiché il modello dinamico è fondamentale per il processo, il tuo design ora è inutile a meno che non torni indietro e lo aggiorni manualmente, cosa che viene eseguita raramente.

A rischio di ripetermi, il processo di andata e ritorno incoraggia i programmatori a ignorare completamente il progetto e solo a codificare, quindi decodificare il codice in immagini ogni tanto. In questa situazione, tuttavia, i programmatori non stanno progettando; stanno hackerando il codice, quindi creano immagini del disordine risultante. L'hacking non è uguale al design.

Sebbene il design sia effettivamente un processo iterativo (il design cambia man mano che il codice viene sviluppato), dovresti iniziare un'iterazione modificando prima il design, quindi refactoring del codice per riflettere il nuovo design. Per fare ciò, dovresti essere in grado di specificare l'intero prodotto software all'interno dello strumento (quando hai premuto il pulsante magico, verrà emesso un programma completamente funzionante) e il processo sarebbe unidirezionale senza un reverse engineering meccanismo.

Gli strumenti CASE

Gli strumenti CASE (computer-aided software engineering) come Rational Rose in genere mettono l'ingegneria di andata e ritorno al centro del prodotto. Tuttavia, poiché l'ingegneria di andata e ritorno non fa nulla di utile, molti sviluppatori utilizzano gli strumenti come costosi programmi di disegno. Degli strumenti disponibili, penso che ne valga la pena considerare tre (anche se non ne uso nessuno):

  • Lo strumento ArgoUML gratuito e open source, scritto in Java, fa un lavoro ragionevolmente buono di diagrammi UML. L'ultima versione tenta persino di guidarti attraverso il processo (con un successo marginale finora, ma è un buon inizio).
  • Il GDPro di Embarcadero, precedentemente distribuito da Advanced Software, offre un buon supporto per un gruppo che lavora su un unico progetto software, ma presenta anche delle carenze in questo reparto. Ad esempio, un designer non può estrarre un diagramma di modello dinamico mentre blocca automaticamente le classi associate agli oggetti sul modello dinamico.
  • Il Together ControlCenter di TogetherSoft aggira il problema del viaggio inverso non facendolo. Il codice e il design vengono visualizzati contemporaneamente sullo schermo e quando si cambia uno, l'altro cambia automaticamente. Tuttavia, ControlCenter non supporta bene i gruppi di programmatori.
  • Dovrei anche menzionare brevemente Visio di Microsoft. Visio è un programma di disegno che in qualche modo supporta UML, ma il suo supporto imita la misera interfaccia utente di Rational Rose. Vari modelli di disegno per le forme UML in Visio funzionano meglio del supporto UML incorporato, incluso uno nella sezione "Goodies" del mio sito web.

Quindi, se penso così male a questi strumenti, cosa devo usare? Gli strumenti di progettazione OO di gran lunga più produttivi sono una lavagna (una stanza con lavagne bianche da parete a parete e dal pavimento al soffitto è l'ideale) e blocchi Post-it delle dimensioni di una lavagna a fogli mobili, i cui fogli possono essere staccati e attaccare al muro. Li ho usati per progettare progetti significativi con grande successo. Inoltre, lavorare su una lavagna richiede molto meno tempo rispetto al wrestling con uno strumento OO CASE.

L'unica difficoltà con l'approccio della lavagna è l'acquisizione delle informazioni sulla lavagna. Le lavagne stampate esistono, ma sono costose, sgraziate e troppo piccole. Un prodotto hardware accurato che tiene traccia del movimento di una penna su una lavagna e acquisisce i tratti della penna nel computer. Altre lavagne funzionano come giganteschi tablet digitalizzatori. Tuttavia, queste soluzioni si dimostrano troppo limitanti; la progettazione avviene simultaneamente sulle lavagne di più uffici, sui tovaglioli, sui ritagli di carta e così via. Non puoi portare una lavagna bianca da 300 libbre al bar locale.

Allora cosa funziona

Allora cosa deve fare una madre? Come si catturano questi artefatti per archiviarli nel computer in modo che forniscano una documentazione ragionevole così com'è, senza doverli trasferire in un programma di disegno?

La soluzione:

  1. Una fotocamera digitale
  2. Un meraviglioso prodotto software chiamato Whiteboard Photo di Pixid

Una foto digitale, sfortunatamente, produce spesso immagini insoddisfacenti per la documentazione. Per compensare, Whiteboard Photo trasforma le immagini digitali in qualcosa di utile. Le immagini valgono davvero più di mille parole, qui. La figura 1 mostra una tipica foto digitale di una lavagna.

La figura 2 illustra un altro esempio.

La Figura 3 mostra il modo in cui Whiteboard Photo trasforma la Figura 1.

Ed ecco come la Figura 2 si prende cura di Whiteboard Photo ha fatto la sua magia.

Come mostrano le immagini, la differenza è sorprendente. Per trasformare l'immagine originale nella versione pulita, ho semplicemente premuto Ctrl-L. Il software ha trovato automaticamente i confini della lavagna, corretto per la distorsione causata dallo scatto dell'immagine da un angolo (necessario per evitare l'abbagliamento del flash), ha individuato le linee del disegno e le ha disegnate. Tutto ciò di cui ha bisogno il prodotto per raggiungere la perfezione è il riconoscimento della scrittura a mano, ma sono stuzzicato dal rosa così com'è. Ora posso produrre disegni di qualità documentaria direttamente dalla lavagna originale, senza sprecare ore a inserire il disegno in qualche debole scusa per uno strumento CASE.

Sii semplice

Nella mia esperienza, quando si tratta di progettazione OO, gli strumenti a bassa tecnologia funzionano meglio. In effetti, sono più veloci, più facili da usare e funzionano bene in ambienti collaborativi. Finora, ho scoperto che la combinazione di una lavagna, una fotocamera digitale e Whiteboard Photo offre il metodo migliore per inserire progetti di programma in una macchina.

Allen Holub fornisce servizi di consulenza, formazione e tutoraggio in progettazione OO, processi OO e programmazione Java. Presenta regolarmente un seminario intensivo di progettazione OO per coloro che sono interessati a sviluppare rapidamente le proprie abilità OO. (Trovate maggiori informazioni su //www.holub.com.) Allen ha lavorato nel settore dei computer dal 1979, più recentemente come chief technology officer presso NetReliance, Inc. È ampiamente pubblicato su riviste (Dr. Dobb's Journal, Programmers Journal, Byte e MSJ, tra gli altri). Allen ha otto libri al suo attivo, l'ultimo dei quali - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - copre le trappole e le insidie ​​del threading Java. Insegna OO design e Java per l'Università della California, Berkeley Extension (dal 1982).

Ulteriori informazioni su questo argomento

  • Per lo strumento di progettazione ArgoUML gratuito e open source, vai a

    //argouml.tigris.org/

  • Il GDPro di Embarcadero può essere trovato su

    //www.embarcadero.com

  • Ulteriori informazioni su TogetherSoft's Together ControlCenter sono disponibili all'indirizzo

    //www.togethersoft.com

  • La home page di Microsoft Visio

    //www.microsoft.com/office/visio/default.htm

  • Vai alla pagina del prodotto Pixid Whiteboard Photo per maggiori informazioni su questo interessante strumento

    //www.pixid.com/home.html

  • Il sito web di Allen Holub presenta la sua pagina "Goodies", dove troverai suggerimenti per la progettazione OO, regole pratiche di programmazione e note da alcuni dei discorsi di Allen

    //www.holub.com/goodies/goodies.html

  • JavaWorld 's Object-Oriented Design e programmazione Index dispone di numerosi articoli di indirizzamento di progettazione

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Troverete maggiori ottime recensioni di prodotto in JavaWorld s' Indice prodotti Recensioni

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Leggi tutto commento in JavaWorld s' Indice Commento

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Per suggerimenti ed esercitazioni su modelli di progettazione, strumenti di sviluppo, ottimizzazione delle prestazioni, sicurezza, test e altro, iscriviti alla nostra newsletter su Java applicato

    //www.javaworld.com/subscribe

  • Parla nella nostra discussione sulla teoria e pratica della programmazione

    //forums.idg.net/[email protected]@.ee6b806

  • Troverai una vasta gamma di articoli relativi all'IT tratti dalle nostre pubblicazioni gemelle su .net

Questa storia, "Quando si tratta di un buon design OO, mantienila semplice" è stata originariamente pubblicata da JavaWorld.