UML
Summary 1.0
_______________________________________________
Copyright © 1997 Rational Software Corporation.
Le fotocopie, la distribuzione elettronica, o la traduzione in altra lingua sono permesse, a patto che questo documento venga riprodotto interamente e accompagnato da queste note, compresa la frase seguente:
Gli aggiornamenti più recenti all’Unified Modeling Language sono disponibili all’indirizzo Web: http://www.rational.com.
_______________________________________________
UML Summary Version 1.0 13 gennaio 1997
Versione Italiana a cura di Adriano Comai
Per la traduzione: Copyright © 1997 Tecnet Dati srl.
La riproduzione integrale in qualsiasi forma di questo documento è permessa, a patto di citare le relative fonti.
_______________________________________________
Sommario
_______________________________________________
Questa serie di documenti descrive lo Unified Modeling Language (UML), un linguaggio per specificare, visualizzare, e creare i prodotti di sistemi software, e anche per il business modeling. L’ UML rappresenta una collezione di “best engineering practices” che si sono dimostrate utili nella progettazione di sistemi complessi e di grandi dimensioni.
La definizione di UML consiste dei seguenti documenti:
UML Summary - E’ il documento che state leggendo. Serve come introduzione a UML e come mappa per orientarsi tra gli altri documenti.
UML Semantics - Il documento descrive il metamodello formale che sta alla base della semantica di UML. Il metamodello di UML viene presentato in notazione UML e in linguaggio naturale sintetico. Come appendice viene incluso un UML Glossary.
UML Notation Guide - Il documento descrive la notazione UML e fornisce esempi.
UML Process-Specific Extensions - descrive le estensioni a UML relative al processo di produzione del software, in termini di meccanismi di estensione e di icone diagrammatiche specifiche per gli aspetti di processo.
Questi documenti sono disponibili sul sito Web della Rational Software, http://www.rational.com. Documentazione addizionale e’ relativa alla proposta di UML all’Object Management Group (OMG) ed e’ disponibile ai membri OMG nei documenti che vanno da ad/97-01-01 a ad/97-01-14. Vedi http://www.omg.org per informazioni su OMG.
Questo insieme di documenti vuole essere innanzitutto una definizione precisa ed autoconsistente dei costrutti semantici e notazionali di UML. Il pubblico primario di questo insieme di documenti comprende l’OMG, altre organizzazioni che definiscono standard, autori, formatori, produttori di strumenti software. Gli autori presuppongono familiarità con i metodi di analisi e disegno object-oriented, e lo stile di scrittura è carico di concetti, ed enfatizza spesso la precisione anche a scapito della comprensibilità. Questi documenti non costituiscono quindi un testo introduttivo sulla progettazione di modelli di oggetti per sistemi complessi, sebbene possano venire utilizzati a questo scopo insieme ad altri materiali o manuali. Questo insieme di documenti diventerà maggiormente comprensibile per un pubblico più ampio quando verranno resi disponibili libri, corsi di formazione e strumenti che applichino l’UML.
1.2 INFORMAZIONI AGGIUNTIVE E AGGIORNAMENTI
Informazioni aggiuntive e aggiornamenti all’UML appariranno sul sito Web della Rational Software, http://www.rational.com/uml.
_______________________________________________
Questa sezione discute l’importanza della modellazione a fronte di requisiti di sistema sempre più complessi.
Perché c’è
bisogno di linguaggi per la definizione di modelli.
Noi costruiamo
modelli dei sistemi complessi perché non siamo in grado di
comprendere un sistema di questo tipo nella sua interezza. Con il
crescere della complessità dei sistemi, cresce anche
l’importanza di buone tecniche di modellazione. Vi sono
molti fattori addizionali che servono al successo di un progetto,
ma disporre di un linguaggio di modellazione standard e rigoroso
è un fattore essenziale. Un linguaggio di modellazione deve
includere:
Il futuro del software
Nel momento in cui
il software aumenta il proprio valore strategico,
l’industria del software cerca tecniche capaci di
automatizzarne la produzione. Cerchiamo tecniche per migliorare
la qualità, e per ridurre i costi e il time-to-market. Queste
tecniche includono il ricorso all’utilizzo di componenti
predefinite (componentware), la programmazione visuale,
l’utilizzo di meccanismi strutturali (patterns), e di
scenari più complessi (frameworks). Cerchiamo anche tecniche per
gestire la complessità dei sistemi quando cresce il loro ambito
di applicazione e la dimensione del loro utilizzo. In
particolare, riconosciamo il bisogno di risolvere problemi
architetturali ricorrenti, come la distribuzione fisica, la
concorrenza, la duplicazione, la sicurezza, il bilanciamento dei
carichi elaborativi, la fault tolerance.
La complessità sarà variabile in funzione del dominio applicativo e della fase del processo di sviluppo. Una delle motivazioni principali nella mente di chi ha sviluppato l’UML era di creare un insieme di costrutti semantici e di notazione che potessero adattarsi in modo adeguato a tutti i livelli di complessità architetturale, in tutti i domini applicativi.
Integrazione di Best
Practices
Una motivazione
chiave per lo sviluppo di UML è stata quella di integrare le
linee di condotta migliori (best practices) esistenti
nell’industria del software, prendendo in considerazione
punti di vista anche molto eterogenei in quanto legati a diversi
livelli di astrazione, domini, architetture, fasi del ciclo di
vita, tecnologie di implementazione, ecc. Gli obiettivi specifici
sono trattati nella sezione successiva.
_______________________________________________
3. PASSATO, PRESENTE E FUTURO DI UML
I precursori di UML
Linguaggi distinti
per la modellazione object-oriented iniziarono ad apparire tra la
metà degli anni ‘70 e la fine degli ‘80, quando vari
metodologi fecero esperienza con approcci diversi
all’analisi e al disegno object-oriented. Il numero di
linguaggi di modellazione, da inferiore a 10 nel 1989, salì a
oltre 50 nel 1994. Molti utilizzatori di metodi OO non trovarono
una soddisfazione completa in alcun linguaggio di modellazione,
alimentando la “guerra dei metodi”. Verso la metà
degli anni ‘90 apparve una nuova iterazione di questi
metodi, in particolare Booch ’93, l’evoluzione di OMT,
e Fusion. Questi metodi iniziarono a incorporare l’uno le
tecniche dell’altro, ed emersero alcuni metodi chiaramente
più significativi, tra cui OOSE, OMT-2, e Booch ’93.
Ciascuno di questi era un metodo completo, ma se ne potevano
distinguere punti di forza specifici. In poche parole, OOSE era
un approccio basato sui casi d’uso che forniva un supporto
eccellente alle attività di business engineering e analisi dei
requisiti. OMT-2 risultava efficace soprattutto per
l’analisi e per sistemi informativi data-intensive.
Booch-’93 risultava particolarmente efficace nelle fasi di
disegno e realizzazione dei progetti, e popolare per le
applicazioni engineering-intensive.
Booch, Rumbaugh, e
Jacobson uniscono le forze
Lo sviluppo di UML
iniziò nell’ottobre 1994, quando Grady Booch e Jim Rumbaugh
della Rational Software Corporation cominciarono a lavorare per
unificare i metodi Booch e OMT (Object Modeling Technique). Dato
che i metodi Booch e OMT stavano già crescendo nella stessa
direzione ed erano considerati a livello mondiale tra i più
importanti metodi object-oriented, Booch e Rumbaugh unirono le
forze per dare forma a una completa unificazione del loro lavoro.
Una bozza del Metodo Unificato (Unified Method - era stato
chiamato così), 0.8, venne rilasciata nell’ottobre del
1995. Sempre nell’autunno del 1995, Ivar Jacobson si unì a
questo sforzo di unificazione, portando con sé il metodo OOSE
(Object-Oriented Software Engineering).
In qualità di autori principali dei metodi Booch, OMT e OOSE, Booch, Rumbaugh e Jacobson erano motivati a creare un linguaggio di modellazione unificato per tre ragioni. Innanzitutto, questi metodi stavano già evolvendo, in modo indipendente, verso una direzione comune. Aveva senso continuare tale evoluzione insieme piuttosto che separatamente, eliminando possibili differenze non necessarie che avrebbero ulteriormente confuso gli utilizzatori. Secondariamente, unificando i significati e le notazioni, avrebbero potuto apportare una certa stabilità al mercato object-oriented , permettendo ai progetti di utilizzare un unico linguaggio di modellazione maturo e lasciando che i produttori di strumenti per lo sviluppo software si focalizzassero sul rilascio di caratteristiche più utili. In terzo luogo, si aspettavano che la loro collaborazione avrebbe portato dei miglioramenti a tutti e tre i precedenti metodi, aiutandoli a cogliere le lezioni emerse dall’esperienza e ad indirizzare correttamente dei problemi che nessuno dei loro metodi gestiva ancora in modo soddisfacente.
All’inizio dell’unificazione, stabilirono quattro obiettivi per focalizzare i loro sforzi:
Definire una notazione utilizzabile per l’analisi e il disegno object-oriented non è molto diverso dal progettare un limguaggio di programmazione. Innanzitutto, è necessario delimitare il problema: la notazione dovrebbe comprendere la specifica dei requisiti? dovrebbe estendersi fino al livello di un linguaggio di programmazione visuale? Secondariamente, è necessario bilanciare tra espressività e semplicità: una notazione troppo semplice limiterebbe l’ampiezza dei problemi che possono essere risolti; una notazione troppo complessa avrebbe un effetto di sopraffazione sullo sviluppatore umano. Unificando metodi esistenti, bisogna anche tenere conto di ciò che è già stato realizzato: fai troppi cambiamenti, e confonderai gli utilizzatori attuali. Fai resistenza al miglioramento della notazione, e perderai l’opportunità di rivolgerti a un insieme molto più ampio di utilizzatori. La definizione di UML cerca di raggiungere il miglior compromesso in ciascuna di queste aree.
Gli sforzi di Booch, Rumbaugh e Jacobson portarono al rilascio dei documenti UML 0.9 e 0.91 nel giugno e nell’ottobre del 1996. Nel corso del 1996, gli autori di UML richiesero pubblicamente e ricevettero dei feedback. Incorporarono tali feedback, ma era chiaro che vi era ancora necessità di altro impegno per focalizzare le questioni ancora aperte.
Nel corso del 1996 divenne chiaro che parecchie organizzazioni ritenevano UML strategico per il loro business. Venne creato un consorzio di partner UML, con molte organizzazioni intenzionate a dedicare risorse per lavorare a una solida definizione di UML. Quelle che hanno contribuito maggiormente alla definizione di UML 1.0 sono state: Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, Texas Instruments e Unisys. Questa collaborazione ha prodotto UML 1.0, un linguaggio di modellazione ben definito, espressivo e potente, e di applicabilità generale.
I partner UML hanno portato in dote esperienze e punti di vista eterogenei, tra cui: prospettive tecnologiche legate a OMG e RM-ODP, business modeling, semantiche relative alle macchine di stato, tipi, interfacce, componenti, collaborazioni, specifiche implementative, scenari, distribuzione, meta-metamodelli. Il risultato finale—UML 1.0—è stato il prodotto di uno sforzo di gruppo collaborativo. Una lista di persone che hanno contribuito alla definizione di UML si trova nella sezione dedicata ai ringraziamenti.
Contemporaneamente alla pubblicazione di questo documento, UML viene sottoposto alla valutazione di OMG per essere adottato come standard.
UML non è un linguaggio proprietario, ed è aperto al contributo di tutti. Si rivolge ai bisogni della comunità degli utilizzatori e a quella scientifica, sulla base dell’esperienza con i metodi da cui è derivato. Molti metodologi, molte organizzazioni e produttori di strumenti per lo sviluppo hanno deciso di utilizzarlo. Dal momento che UML è definito a partire da significati e notazioni derivati da Booch, OMT, OOSE e altri metodi primari, ed ha incorporato i suggerimenti dei partner UML e il feedback di tutti coloro che hanno collaborato, dovrebbe derivarne una sua adozione generalizzata.
Sono due gli aspetti di “unificato” che UML permette di ottenere: innanzitutto, pone termine a molte tra le differenze, spesso non necessarie, tra i linguaggi di modellazione dei metodi precedenti. In secondo luogo, ma con un’importanza forse maggiore, unifica le prospettive tra molte diverse tipologie di sistemi (business versus software), fasi di sviluppo (analisi dei requisiti, disegno, e progettazione), e concetti implementativi.
Nel momento in cui scriviamo queste cose, le prossime tappe pianificate sono:
Standardizzazione di
UML
Molte
organizzazioni hanno già annunciato l’utilizzo di UML come
standard interno, dal momento che è basato sui linguaggi di
modellazione di metodi OO di rilevanza primaria. UML è pronto
per venire utilizzato in modo generalizzzato. La release 1.0 di
UML è una versione stabile ed utilizzabile. Questi documenti
sono adatti a costituire la fonte primaria per la scrittura di
testi e materiale didattico, così come per lo sviluppo di
strumenti per la modellazione visuale. Materiale aggiuntivo, come
articoli, corsi di formazione, esempi e libri, renderanno presto
UML comrensibile per un pubblico molto ampio.
Nel gennaio 1997, la documentazione della versione 1.0 di UML verrà sottoposta, insieme ad altre, come risposta alla richiesta di proposta (RFP-1) effettuata dalla Analysis & Design Task Force dell’Object Management Group (OMG. OMG deciderà sull’adozione di UML come standard, si spera verso la metà del 1997. Come accade per tutte le definizioni, aspettatevi che UML evolva. Il processo di preparazione della documentazione per OMG, ad esempio, ha costituito e continuerà a costituire un’importante fonte di suggerimenti.
Gruppi di discussione e
feedback
Esistono numerosi
forum di discussione elettronici appropriati alla discussione
generale su UML, tra cui il newsgroup internet comp.object.
I partner UML registreranno e prenderanno in considerazione i commenti a UML inviati per e-mail a uml_feedback@rational.com. Commenti costruttuvi che facciano riferimento a sezioni specifiche dei documenti UML saranno più facili da incorporare. In funzione del volume dei commenti, è possibile che non saremo in grado di rispondere a ciascuna e-mail individualmente.
Industrializzazione
Molte aziende e
produttori di software hanno già aderito a UML. Il numero di
aziende che lo utilizzeranno ci si aspetta che cresca in modo
considerevole nel prossimo futuro. Queste organizzazioni
continueranno ad incoraggiare l’utilizzo di UML rendendone
la definizione agevolmente disponibile ed incoraggiando altri
metodologi, produttori di strumenti software, aziende che operano
nella formazione ed altri soggetti ad adottare UML.
La vera misura del successo di UML sarà il suo utilizzo in progetti di successo, e la crescita della domanda per strumenti di supporto, libri, formazione e consulenza.
_______________________________________________
Lo Unified Modeling Language (UML) è un linguaggio per specificare, realizzare, visualizzare e documentare i prodotti di un sistema software.
Innanzitutto, lo Unified Modeling Language unifica i concetti dei metodi Booch, OMT e OOSE. Il risultato è un unico, comune, ampiamente utilizzabile linguaggio di modellazione per gli utilizzatori di questi ed altri metodi.
In secondo luogo, lo Unified Modeling Language amplia i limiti di ciò che poteva venire effettuato con i metodi esistenti. In particolare, gli autori di UML hanno indirizzato il proprio sforzo alla modellazione di sistemi distribuiti con problemi di concorrenza, e UML contiene elementi per la gestione di tali ambiti.
In terzo luogo, lo Unified Modeling Language è un linguaggio di modellazione standard, non un processo standard. Anche se UML deve essere applicato nel contesto di un processo di produzione del software [una “metodologia” - nota del traduttore], la nostra esperienza è che la diversità delle organizzazioni e la diversità degli ambiti di utilizzo (problem domains) richiedono processi di produzione differenziati. (Per esempio, il processo di sviluppo di piccole componenti riusabili - shrink-wrapped software - è molto interessante, ma realizzare piccole componenti riusabili è molto diverso dal realizzare sistemi aeronautici hard-real-time dai quali dipende la vita di esseri umani). Pertanto gli sforzi si sono concentrati innanzitutto su un metamodello comune (che rendesse univoci i concetti semantici) e secondariamente su una notazione comune (che fornisce agli esseri umani una visualizzazione di questi concetti). Non è detto che gli autori di UML definiranno un processo standard, anche se continueremo a promuovere un processo di sviluppo basato sui casi d’uso, incentrato sulle architetture, iterativo ed incrementale (use-case driven, architecture centric, and iterative and incremental).
Quali sono i prodotti primari di UML? Si può rispondere a questa domanda da due diversi punti di vista: la definizione di UML e come UML viene utilizzato per realizzare i prodotti di progetto.
4.1.1 Prodotti che definiscono
UML
Per agevolare la
comprensione dei prodotti che costituiscono lo Unified Modeling
Language (la visione “interna”) questa documentazione
comprende i singoli documenti: UML Summary (che state leggendo in
questo momento), UML Semantics, UML Notation Guide, e UML
Process-Specific Extensions. Un inquadramento per la comprensione
di questi documenti viene descritto più avanti. Oltre a questi
documenti, sono pianificati dei libri che miglioreranno la
comprensibilità, con esempi e stili di utilizzo comuni.
4.1.1.1
UML Semantics
Il documento UML Semantics descrive il modello che sta alla base
di UML, presentato sia in forma testuale che nella stessa
notazione di UML. I partner di UML iniziarono il proprio lavoro
sulla base di un metamodello preciso, utilizzando la notazione
UML corredata da testo in inglese. Lo scopo del metamodello era
di fornire una definizione univoca, comune e definitiva della
sintassi e della semantica di UML. La presenza di questo
metamodello ha reso possibile ai suoi autori di trovare un
accordo sugli aspetti semantici, separandoli dalle modalità con
cui i significati vengono resi accessibili agli esseri umani.
Inoltre, il metamodello ha dato al gruppo di lavoro la
possibilità di trovare delle strade per rendere il linguaggio di
modellazione molto più semplice, consentendo di trattare in modo
univoco gli elementi dell’Unified Modeling Language. (Ad
esempio, vennero scoperti aspetti comuni tra i concetti di tipo,
pattern e caso d’uso). Gli autori si aspettano che il
contributo di altri studiosi possa esprimere questo metamodello
in termini ancor più precisi, tramite il ricorso a tecniche
formali.
Un metamodello è un linguaggio per specificare un modello, in questo caso un modello a oggetti. I metamodelli sono importanti in quanto possono fornire una definizione univoca, comune e non ambigua della sintassi e della semantica di un modello. Il “livello meta” in un modello è in qualche modo arbitrario, e gli autori di UML hanno scelto consapevolmente un livello ricco dal punto di vista semantico, in quanto un tale livello risulta necessario per consentire un accordo sugli aspetti di significato necessari per lo scambio di informazioni tra strumenti diversi e per il disegno di sistemi complessi.
4.1.1.2
UML Notation Guide
Il documento UML
Notation Guide descrive la notazione UML e fornisce degli esempi.
La notazione grafica e la sintassi testuale costituiscono la
parte più visibile di UML (la visione “pubblica”),
utilizzata da esseri umani e strumenti per modellare i sistemi.
Si tratta di rappresentazioni di un modello a livello di
utilizzatore (user-level model), che dal punto di vista semantico
costituisce un’istanza del metamodello UML. I tipi di
diagramma standard vengono elencati in una sezione successiva.
4.1.1.3 UML Process Extensions
Il documento UML
Process Extensions propone alcuni valori specifici per i
meccanismi di estensione di UML (stereotipi, tagged values,
vincoli) relativamente agli aspetti legati al processo di
produzione del software, e le icone associate a tali valori,
quando ne esistono.
4.1.2 Prodotti generati dai progetti di sviluppo
La scelta di quali proiezioni del modello creare ha un’influenza profonda sui modi di affrontare un problema e di delinearne la soluzione. L’astrazione, cioè il focalizzarsi su alcuni aspetti rilevanti ignorandone altri, è una chiave sia per la comprensione che per la comunicazione. Pertanto:
In termini di viste logiche di un modello, UML prevede la definizione dei seguenti diagrammi:
Questi diagrammi forniscono nel loro insieme molteplici prospettive sul sistema che viene analizzato o sviluppato. Il modello sottostante integra queste prospettive permettendo che l’analisi e lo sviluppo mantengano uno stato di consistenza del sistema. Questi diagrammi, insieme alla documentazione di supporto, sono i prodotti primari su cui opera il progettista, anche se l’UML e gli strumenti di supporto forniranno anche altre viste logiche derivate dal modello. Questi diagrammi vengono ulteriormente descritti nel documento UML Notation Guide.
Notazione e storia dei
significati
UML costituisce un’evoluzione di Booch, OMT, OOSE, della
maggior parte degli altri metodi object-oriented, e di molte
altre fonti. Queste varie fonti avevano incorporato molti
elementi diversi provenienti da vari autori, anche con influenze
estranee all’object-oriented. La notazione UML è il
risultato dell’unione di spunti grafici provenienti da fonti
eterogenee, con la rimozione di alcuni simboli (che si prestavano
a confusione, superflui, o poco usati) e l’aggiunta di
alcuni altri. Le idee presenti in UML derivano dalle idee
suggerite da molte persone attive nel campo
dell’object-oriented. Molte di queste idee non scaturiscono
dagli autori di UML; il ruolo di questi è stato quello di
selezionare ed integrare idee dalle migliori fonti dell’OO e
dell’informatica. L’effettiva genealogia della
notazione e dei concetti semantici che ne stanno alla base è
piuttosto complessa, e viene commentata qui solo per fornire un
contesto di significato, non per stabilirne con precisione la
storia.
I diagrammi dei casi d’uso (Use-case diagrams) sono simili come aspetto a quelli di OOSE.
I diagrammi delle classi (Class diagrams) derivano da OMT, da Booch, e dai diagrammi delle classi della maggior parte degli altri metodi OO. Le estensioni relative al processo (cioè stereotipi e icone corrispondenti) possono essere utilizzate in numerosi diagrammi per supportare altri stili di modellazione.
I diagrammi di transizione di stato (State diagrams) sono basati sostanzialmente sui diagrammi di Harel con modifiche secondarie. I diagrammi delle attività (Activity diagram), che hanno alla base molti significati in comune con i diagrammi di transizione di stato, sono simili ai diagrammi di workflow proposti da varie fonti, anche precedenti all’OO.
I diagrammi di sequenza (Sequence diagrams) vennero proposti in numerosi metodi OO con nomi diversi (interaction, message trace, e event trace) e risalgono a prima dell’object-oriented. I diagrammi di collaborazione (Collaboration diagrams) sono stati adattati da Booch (object diagram), Fusion (object interaction graph), ed alcune altre fonti.
Le collaborazioni (Collaborations) costituiscono ora delle entità di modellazione primarie, e formano sovente la base per i patterns.
I diagrammi di implementazione (diagramma delle componenti - component - e diagramma di allocazione - deployment -) derivano dai diagrammi module e process di Booch, ma sono ora incentrati sulle componenti anziché sui moduli, ed è migliorato il loro collegamento.
Gli stereotipi (Stereotypes) costituiscono uno dei meccanismi di estensione per i significati del metamodello. Per ogni stereotipo possono venire definite dall’utilizzatore delle icone, allo scopo di adattare l’UML a specifici processi di sviluppo.
Ciascuno di questi concetti ha altri predecessori e molte altre derivazioni. Capiamo che ogni lista abbreviata di influenze è incompleta, e riconosciamo che UML è il prodotto di una lunga storia di idee nell’informatica e nell’area del software engineering.
La definizione di UML 1.0 volutamente evita di trattare standard per gli strumenti di supporto allo sviluppo e per le modalità di produzione del software, dal momento che questi aspetti sono effettivamente a sé stanti. Standardizzare un linguaggio costituisce la base per gli strumenti di supporto allo sviluppo e per il processo di produzione del software.
Tools
La richiesta formulata dall’Object Management Group (OADTF
RFP-1) ha contribuito a stimolare la definizione di UML.
L’obiettivo primario della richiesta era garantire
l’interoperabilità tra strumenti diversi. In ogni caso, gli
strumenti e la loro interoperabilità hanno una stretta
dipendenza dalla presenza di una definizione solida degli aspetti
semantici e di notazione come quella fornita da UML. Anche se UML
definisce un metamodello semantico, e non un metamodello relativo
agli strumenti, questi due aspetti dovrebbero risultare
sufficientemente collegati, e lo scambio di informazioni tra
strumenti diversi può venire definito in modo consistente con la
definizione degli aspetti semantici e di notazione.
In coincidenza con l’ivio di UML all’OMG, i partner UML hanno inviato anche una definizione di interfaccia per gli strumenti compatibile con UML, utilizzando gli standard CDIF/EIA relativamente alla codifica ed alla sintassi di import / export.
I documenti UML comprendono alcuni suggerimenti per i fornitori in merito alle scelte implementative, ma non affrontano tutti i punti da considerare. Ad esempio, non ci si occupa dell’aspetto dei diagrammi, del colore, delle modalità di lavoro per l’utilizzatore, delle animazioni e di altri aspetti importanti.
Modalità di produzione
del software (Process)
Molte organizzazioni utilizzeranno UML come linguaggio comune per
realizzare i prodotti di progetto, ma utilizzeranno i medesimi
diagrammi UML nell’ambito di modalità di sviluppo diverse.
UML è intenzionalmente slegato dalle modalità di sviluppo, e la
definizione di una modalità di sviluppo standard non rientrava
tra gli obiettivi di UML, né della richiesta formulata da OMG.
Gli autori di UML, comunque, riconoscono l’importanza della modalità di produzione del software. L’esistenza di un processo ben definito e ben gestito è un fattore chiave per capire la differenza tra progetti ad elevata produttività e progetti fallimentari. Far conto su modalità di programmazione basate sull’eroismo non è una strada praticabile. Un processo ben definito 1) fornisce linee guida sulla sequenza delle attività di un gruppo di lavoro, 2) specifica quali prodotti devono essere sviluppati nelle varie fasi, 3) guida i compiti dei singoli individui e del gruppo, e 4) fornisce criteri per il monitoraggio ed il controllo dei prodotti e delle attività di progetto.
Le modalità di produzione del software devono venire adattate alle caratteristiche organizzative, culturali ed applicative in cui sono calate. Ciò che funziona in un contesto (sviluppo di piccole componenti riusabili -shrink-wrapped software-, ad esempio) produrrebbe disastri se applicato altrove (ad esempio sistemi hard-real-time). La scelta di una particolare modalità di sviluppo varia fortemente in funzione dell’ambito applicativo, della tecnologia implementativa, e delle competenze di chi lavora.
Booch, OMT, OOSE, e molti altri metodi prevedono una modalità di sviluppo specifica e ben definita, e UML può essere utilizzato con la maggior parte dei metodi. Si sono verificate delle convergenze sulle modalità di sviluppo, ma non esiste ancora un consenso sufficiente per una standardizzazione. Ciò che probabilmente accadrà è un accordo generale sugli stili migliori di progettazione, e forse il delinearsi di uno scenario globale per la produzione del software, nell’ambito del quale verranno istanziate delle specifiche modalità di sviluppo. Anche se UML non prescrive un’unica modalità di sviluppo, i suoi autori riconoscono il valore di una modalità di sviluppo basata sui casi d’uso, incentrata sulle architetture, iterativa ed incrementale, e sono stati attenti a renderla possibile (anche se non a renderla obbligatoria) nell’utilizzo di UML.
4.3 CONFRONTO DI UML CON I LINGUAGGI DI MODELLAZIONE DI BOOCH, OMT, OOSE E ALTRI METODI
Dev’essere chiaro che lo Unified Modeling Language non è una strada radicalmente diversa rispetto a Booch, OMT o OOSE, ma piuttosto il successore legittimo di tutti e tre. Ciò significa che se voi oggi utilizzate Booch, OMT o OOSE, la vostra formazione, l’esperienza e i tool che utilizzate saranno salvaguardati, in quanto lo Unified Modeling Language ne costituisce una naturale evoluzione. L’adozione di UML risulterà ugualmente semplice per gli utilizzatori di molti altri metodi, ma spetterà agli autori di questi il decidere se adottare i concetti e la notazione di UML nell’ambito del proprio metodo.
Lo Unified Modeling Language è più espressivo, ma tuttavia più lineare ed uniforme rispetto a Booch, OMT, OOSE, e altri metodi. Ciò significa che l’adozione di UML è vantaggiosa, perché permetterà ai progetti di modellare degli aspetti che in precedenza non avrebbero potuto venire descritti in modo efficace. Gli utilizzatori della maggior parte degli altri metodi e linguaggi di modellazione otterranno dei vantaggi passando a UML, dal momento che esso rimuove le differenze non necessarie a livello di notazione e di terminologia che nascondono il fatto che molti di questi approcci sono affini tra loro.
Rispetto ad altri linguaggi di modellazione visuale, tra cui i modelli entity-relationship, i flow chart BPR e i linguaggi per la definizione degli stati, UML dovrebbe risultare maggiormente espressivo e con una migliore integrità olistica.
Gli utilizzatori dei metodi precedenti troveranno qualche cambiamento nella notazione, che non dovrebbe però richiedere molta nuova formazione e porterà di contro ad una chiarificazione dei concetti. Se gli obiettivi dell’unificazione sono stati raggiunti, l’UML diventerà una scelta naturale all’inizio dei nuovi progetti, soprattutto quando vi sarà disponibilità di strumenti, libri e corsi di formazione. Molti strumenti di modellazione visuale offrono supporto alle notazioni precedenti, come quelle di Booch, OMT, OOSE, e altri metodi, come viste logiche di un modello sottostante; quando aggiungeranno il supporto a UML (come per alcuni è già avvenuto) gli utilizzatori avranno il vantaggio di poter convertire i loro attuali modelli nella notazione UML senza perdita di informazioni.
Gli utilizzatori attuali di qualsiasi metodo OO possono aspettarsi una curva di apprendimento decisamente veloce per ottenere la stessa capacità espressiva che avevano prima. Gli elementi di base possono essere appresi produttivamente in fretta. Alcune tecniche più avanzate, come l’utilizzo di stereotipi e delle proprietà, richiederanno un certo studio, dal momento che rendono possibile la creazione di modelli molto espressivi e precisi, necessari solo quando il problema che si sta affrontando li richiede.
4.4 NUOVE CARATTERISTICHE DI UML
Gli obiettivi dei lavori di unificazione erano di mantenere UML semplice, di eliminare dai metodi Booch, OMT e OOSE degli elementi poco efficaci nella pratica, di aggiungere elementi più efficaci derivati da altri metodi, e di inventare qualcosa di nuovo solo quando nessun’altra soluzione esistente risultasse disponibile. Dal momento che gli autori di UML stavano di fatto definendo un linguaggio (anche se grafico), avevano la necessità di trovare un corretto punto di equilibrio tra un approccio minimalista (solo testo e rettangoli) ed uno iperspecializzato (un’icona diversa per ciascun elemento di modellazione concepibile). A questo fine, sono stati molto cauti nell’introduzione di nuove cose, perché non volevano rendere UML più complesso del necessario. Alcune, però, le hanno aggiunte, che si erano dimostrate efficaci in altri contesti di modellazione.
Ci sono parecchi nuovi concetti inclusi in UML, tra cui:
Molte di queste idee erano già presenti in vari metodi e teorie, ma UML li racchiude in un insieme coerente. Oltre a queste variazioni principali, vi sono numerosi miglioramenti di dettaglio rispetto alla notazione ed alla semantica di Booch, OMT e OOSE.
_______________________________________________
In questa sezione vengono riconosciuti gli sforzi di coloro che hanno contribuito in modo significativo alla definizione di UML 1.0 e all’obiettivo di renderla un successo. Come detto sopra, potete mandare via e-mail feedback specifici su UML all’indirizzo uml_feedback@rational.com.
Metodologi UML
Gruppo di lavoro primario per UML 1.0
Altre persone che hanno contribuito e fornito supporto Riconosciamo i contributi, l’influenza e il supporto delle singole persone sotto elencate. In pochissimi casi, alcune di queste persone non hanno aderito ufficialmente a UML, ma in ogni caso il loro contributo è stato apprezzato.
Hernan Astudillo, Dave Bernstein, Michael Blaha, Gary Cernosek, Michael Jesse Chonoles, Magnus Christerson, Dai Clegg, Peter Coad, Derek Coleman, Steve Cook, Ward Cunningham, Raj Datta, Mike Devlin, Bruce Douglass, Staffan Ehnebom, Maria Ericsson, Johannes Ernst, Don Firesmith, Martin Fowler, Eric Gamma, Dipayan Gangopadhyay, Richard Helm, Michael Hirsch, Yves Holvoet, Jon Hopkins, John Hsia, Ralph Johnson, GK Khalsa, Philippe Kruchten, Paul Kyzivat, Martin Lang, Mary Loomis, Robert Martin, Bertrand Meyer, Mike Meier, Randy Messer, Greg Meyers, Paul Moskowitz, Gunnar Overgaard, Jan Pachl, Bill Premerlani, Jeff Price, Jerri Pries, Terry Quatrani, Rich Reitman, Rudolf M. Riess, Kenny Rubin, Danny Sabbah, Ed Seidewitz, Gregson Siu, Jeff Sutherland, Dan Tasker, Andy Trice, Dan Uhlar, John Vlissides, Paul Ward, Rebecca Wirfs-Brock, Bryan Wood, Ed Yourdon, e Steve Zeigler.
_______________________________________________
