Presentazione del prodotto
Come già asserito, si tratta di un software scritto in pure Java, che quindi ne eredita difetti e virtù. Tra i pregi si può contemplare il fatto che sia virtualmente disponibile su ogni piattaforma che disponga di una JVM, anche se si sa bene che non tutte le VM sono gioielli di ingegneria del SW e, per ottenere la tanto agognata cross-plataform, spesso è necessario ricorrere a veri e propri trucchetti. Un altro pregio è la presenza di un Look&Feel selezionabile, e così via.
I difetti sono tristemente ben conosciuti, l’interfaccia utente talune volte sembra presentare qualche piccolo problema (vedi mancati refresh e situazioni di “stallo”), le performance non sono eccezionali, timore di improvvise saturazioni della memoria virtuale (ebbene anche il virtuale si satura!), ecc..
Ciononostante, nel compendio totale e nel confronto con gli altri Software, a mio avviso, ne esce comunque molto bene.
E’ appena il caso di sottolineare che un paragone tra Rose e MagicDrawUML non si dovrebbe neanche pensare per via dell’elevato dislivello dei costi: ben un ordine di grandezza! In altre parole, sarebbe come paragonare un’utilitaria con una macchina di lusso. Comunque il livello qualitativo sembra molto affine, anche per via dell’eccezionale somiglianza dei due tool.
Una prima grande differenza risiede nella modalità di organizzare i progetti: MagicDrawUML non permette una strutturazione basata sulle viste UML. Personalmente trovo che, specie per i progetti di medio/grandi dimensioni, tale organizzazione permetta di raggiungere una migliore organizzazione: si possono realizzare più versioni di uno stesso diagramma, ciascuna caratterizzate da diversi livelli di astrazione in funzione della vista di appartenenza. Per esempio, si può produrre un Sequence Diagram al livello di Use case View, molto generale, ed una corrispondente versione nella Logical View, con un grado di astrazione molto basso.
Questa differenza di organizzazione, va tenuta presente se si intende esportare i file MagicDraw per elaborarli con Rose. Infatti, se si decisse di denominare un diagramma use case, “Use case view”, probabilmente Rose potrebbe non gradire molto questa mancanza di fantasia.
Un altro inconveniente è legato al fatto che MagicDrawUML utilizza un proprio dispositivo di “ClipBoard” (Java). Se da un alto è molto utile per questioni di portabilità, dall’altro può creare qualche problema di scambio immagini tra applicazioni. Tale inconveniente viene aggirato dalla possibilità di esportare i diagrammi in formato “jpeg” (non sempre perfetti).
Comunque, avviando il MagicDrawUML, la prima cosa che colpisce è la presenza, sulla tool bar, di un’icona dedicata agli Activity Diagram, ebbene sì, contrariamente a Rose, i progettisti di MagicDraw si sono ricordati che nella proiezione dinamica della “logical View” è contemplata tale tipologia di diagramma.
Ma, procediamo con ordine.
 
 
 

Use case
Generando un diagramma di Use Case viene visualizzata una nutrita tool bar dedicata a tali tipi di diagramma. Purtroppo si osserva subito l’esistenza di uno stereotipo errato, ossia lo “<<uses>>”. Si tratta di un errato retaggio delle prime versioni di UML. Infatti, quando un “use case” ne utilizza un altro, la relativa relazione non può essere espressa per mezzo di una generalizzazione; ciò equivarrebbe ad asserire che lo use case “utilizzatore” possa essere sempre sostituito al posto dello use case “utilizzato”, il che è palesemente errato. Quindi venendo a mancare la condizione fondamentale della Generalizzazione, manca totalmente la relazione. Nelle versioni più recenti dell’UML si è saggiamente deciso di utilizzare uno stereotipo del legame di dipendenza, denominato “<<include>>”. Purtroppo, in MagicDrawUML, non è possibile collegare due use case (funzioni) per mezzo di un legame di dipendenza.
Poco male, gli stessi problemi sono presenti anche in Rose!
Disegnando il primo attore, si vede che compare su sfondo arancione… Utilizzare un giallino sarebbe stato veramente troppo! Comunque la cosa simpatica è che è possibile selezionare l’aspetto desiderato (font, colore del font, backgorund, ecc.) per ogni oggetto, permettendo di dare risalto alle componenti desiderate. Tracciando i vari link si osserva anche che è anche possibile selezionare i punti in cui ancorarli, sia sull’oggetto di partenza, sia su quello di arrivo. L’importanza di ciò è comprensibile solo a coloro che hanno litigato con Rose e con relativa la funzione “Autosize All”. Conseguenza di ciò, tra l’atro, è la possibilità di disegnare più link tra gli stessi oggetti.
Un’altra cosa molto interessante derivata dal fatto che gli oggetti, ed il testo inserito, tendono a permanere nella posizione prescelta.
Infine è possibile evidenziare i confini del sistema per mezzo dell’icona “draw system boundary”.
 
 
 

Figura 1 Use case di esempio generato con MagicDrawUML.

Class Diagram
Per ciò che concerne i “Class Diagram”, non sembra mancare proprio nulla, anzi…
La prima cosa che colpisce è la possibilità di realizzare, molto agevolmente, più self-associations riferite alla stessa classe (vedere figura 2, grafico ad effetto specie per le stampanti). Gli utilizzatori Rose sanno cosa significhi!
Un altro fattore di interesse è che gli elementi statici (attributi/metodi) vengono effettivamente visualizzati sottolineati, come previsto da UML e non con un carattere $ premesso.
Ancora, nelle classi viene riportato lo stereotipo, qualora presente, come da prassi, nonché eventuali “Tagged Values” (testo riportato sotto il nome della classe).
 
 
 

Figura 2 Esempio di class diagram

In figura 3 è mostrata un esempio di relazione ternaria tra le classi, anch’essa degna di nota.
 

Figura 3 Esempio di relazione ternaria

Un altro elemento interessante è la possibilità di visualizzare le “inner calss” (classi annidate).
 
 
 

Object Diagram
Si tratta della famosa istantanea del sistema relativa ad un preciso istante, realizzata al fine di evidenziare e spiegare concretamente i legami esistenti tra gli oggetti (vedere [8]). Come nel caso degli altri tool, il diagramma è stato ignorato.
 
 
 

Sequence Diagram
La versione MagicDraw di tali diagrammi è esaltante. Si tratta di un vero piacere realizzarli, specie se si è subita l’autogestione che Rose applica in questo contesto.
Per avere qualche esempio, si consideri la figura 4.
 

Figura 4 Esempio di sequence diagram

La prima cosa che cattura l’attenzione è la rappresentazione dello stereotipo “<<create>>” (messaggio 5 di figura). Ebbene il rettangolo con il nome dell’oggetto viene riportato poco prima del messaggio, come da specifiche, anziché in alto con tutti gli altri.
Un'altra finezza apprezzata è il segno grafico “X” posto ad indicare l’esplicita distruzione dell’oggetto (in questo caso “Order”, messaggio 12), sempre come da specifiche UML. Ancora, la presenza del blocco condizionale (messaggi 4 e 5) rende il diagramma più chiaro, evitando la necessità di doverne realizzare diverse versioni, ciascuna dedicata alla descrizione dello “scenario” generato dall’esito di ciascuna condizione. 
Non ultimo è l’elevato livello di “organizzazione e pulizia” evidenziata del grafico, difficilmente raggiungibile attraverso altri tool.
Il sottositema demandato alla generazione dei Sequence Diagram è sicuramente ben riuscito, il che non è poco se si considera che questo diagramma è il più utilizzato nella rappresentazione della proiezione dinamica della “Logical View”.
Qualche pecca? Ebbene sarebbe stato utile inserire la funzione (prevista da Rose) che, a partire da un Sequence Diagram, genera automaticamente il relativo Collaboration.
Spesso, in fase di modellazione capita di partire con un Sequence Diagram per poi rendersi conto, per motivi di leggibilità, di dover optare per un Collaboration.
 
 
 

Collaboration Diagram
Per quanto riguarda i collaboration diagram, non c’è molto da dire: tutto come da manuale; così come lo è anche per gli altri tool.
Molto valida è la sintassi legata al flusso dei messaggi, con la possibilità di organizzarli gerarchicamente.
 
 
 

Activity Diagram
Si tratta della versione UML del famossissimo Flow Chart. Nel contesto della modellazione Object Oriented, viene utilizzato per la modellazione dell’aspetto dinamico del sistema. 
 
 
 

Figura 5  Esempio di Activity Diagram

Alcune parti potrebbero essere migliorate, specie quelle relative ai blocchi per l’invio e la ricezione dei messaggi (signal send, signal receipt). In particolare sarebbe opportuno permettere di visualizzare la connessione con le entità esterne, destinatarie/mittenti dei segnali.
Comunque esiste la possibilità di realizzare tale tipologia di diagramma, il che non è poco visto che gli altri tool derogano tale attività ad altri programmi.
 
 
 

State Diagram
Anche l’editor di state diagram rientra tra le funzionalità degne di nota. In questo caso i diagrammi sono svincolati dalle classi. I pro di questa scelta sono legati al fatto che si possano rappresentare facilmente state diagram relativi a più classi; il contro è la navigabilità meno immediata.
 
 
 

Figura 6 Esempio di state diagram di login.

Implementation Diagram
Immagino che la lettura del titolo di questo paragrafo possa ingenerare qualche perplessità: vi confesso che è successo anche a me! Cosa sono gli Implementation Diagram? Nuovi aggiornamenti UML?
Nulla di tutto ciò.
Con tale denominazione, MagicDraw si riferisce ai Component e Deployment diagram.
In sostanza viene data la possibilità di realizzare un solo diagramma rappresentante l’unione delle due viste.
Come si può notare dalla figura 7, l’aspetto è molto chiaro e gradevole, e comunqe, nulla vieta di realizzare le due viste separatamente come da standard UML.
 
 

Figura 7 Esempio di “implementation diagram”

Features mancanti
Una funzionalità particolarmente apprezzata in altri tool e qui mancante, è la produzione automatica di un ipertesto costituito da pagine HTML contenenti i diagrammi di modellazione del sistema, corredati dalle varie note. In altre parole, la produzione automatica di un “sito documentale” del progetto.
Tra le feautures da migliorare c’è la funzione di reverse engineering. Allo stato attuale, DrawMagicUML è in grado di acquisire egregiamente tutti i dati relativi alle classi che compongono il progetto, però per la produzione dei relativi diagrammi è necessario utilizzare il “new class diagram wizard”.
Un'altra piccola lacuna, imputabile in parte alle API Java, è la rudimentale funzionalità di Drag & Drop. Estendendola opportunamente e prevedendola in più parti, l’usabilità del programma ne risentirebbe positivamente.
 
 
 

Conclusioni
Nel presente articolo è stato presentato, con relative luci ed ombre, un prodotto di supporto alla modellazione dei sistemi Object Oriented che può vantarsi, a pieno titolo, di essere l’alternativa a Rational Rose.
Inoltre, probabilmente, è anche quello che accoglie più di ogni altre le direttive del linguaggio UML.
Tra pregi e difetti, emerge imperioso il basso costo: 500 U.S.A. Dollar per la versione professional, che lo rende particolarmente indicato ad aziende di medio/piccole dimensioni e a tutti coloro che cominciano ad intraprendere la strada, sempre scarsamente praticata, della progettazione Object Oriented: proprio a questo si devono i toni di carattere “propagandistico” presenti nell’articolo.
Chissà che proprio questo prodotto concorra, in maniera determinante, alla soppressione dell’ultimo alibi innalzato a difesa della ritrosia alla progettazione Object Oriented: l’elevato costo dei tool.
Comunque, in estrema sintesi, si può dire che si tratta di un buon prodotto che, opportunamente aggiornato con l’introduzione di nuove features, potrà contendere a Rose una buona fetta di mercato.
Un ultimo aspetto che va considerato è la scelta coraggiosa ed evoluta di realizzare un Software visuale in pure Java.
 
 
 

Bibliografia

[1] The Unified Modeling Language User Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley

[2] UML Toolkit
Hans-Erik Eriksson, Magnus Penker
Wiley

[3] The Unified Modeling Language Reference Manual
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley

[4] Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch
Addison Wesley.

[5] www.omg.org
Si tratta del sito ufficiale del Object Managment Group.

[6] www.mokabyte.it, numero 34 (Ottobre 1999)
UML e lo sviluppo del software.

[7] www.mokabyte.it, numero 35 (Novembre 1999)
Use Case: l’analisi dei requisiti secondo l’U.M.L.

[8] www.mokabyte.it, numero 36 (Dicembre 1999)
Diagrammi delle classi e degli oggetti: proiezione statica della Design View.

[9] www.mokabyte.it, numero 37 (Gennaio 2000)
Proiezione statica della “Design View” parte seconda: esempi “celebri” di diagrammi delle classi..