INDICE

.Descrizione progetto

Introduzione all'ingegneria del software

2.1 Metodi di sviluppo

2.2 Introduzione all'UML e suoi obbiettivi

Lo standard UML

Contenuti del documento Sommario UML

3.2 Intestazione del documento Semantiche UML

Proposta di un progetto secondo lo standard

Conclusioni

Appendici

Traduzione del manuale UML

Prove di traduzione

Analisi della traduzione

Scelta del software e considerazioni

Esempio di traduzione con il software scelto

Storia e cronaca dell'UML

Conversine di nomi e digitazioni dall'UML

Strumenti basati sull'UML

Rational Rose 98 Enterprise Edition

Glossario dell'UML

OCL

Software usato

Bibliografia

1. DESCRIZIONE PROGETTO

L'analisi dell'UML è stata considerata come un interessante progetto da proporre vista la vasta utilizzazione di questo standard e le relative affidabilità pratiche che esso può offrire. Le realizzazione riguarda principalmente le materie informatica e sistemi. La materia inglese è stata poi inclusa vista la necessità di una traduzione di parte delle metodologie dello standard, fornite in un manuale in lingua inglese.

La prima fase del progetto riguarda il recupero del manuale contenente lo standard UML e della documentazione necessaria per una descrizione dell'ambito del progetto, sono stati reperiti informazioni e articoli sull'ingegneria del software e sulle basi storiche di UML.

Lo svolgimento è stato integrato da una prova di traduzione attraverso dei prodotti software. Tali prodotti sono stati reperiti principalmente da internet (gli indirizzi delle case costruttrici sono forniti dai docenti). Prime di effettuare la traduzione sono state analizzate le possibilità e la precisione del software basandosi su particolari aspetti dell'inglese tecnico e non. I risultati hanno però deluso le aspettative, nonostante la buona qualità dei software (per ulteriori particolarità si rimanda all'appendice «Traduzione del manuale UML»).

L'intenzione iniziale del progetto era quella di proporre una traduzione completa del manuale, dopo un'analisi del testo prodotto dai software e verificata la necessità di una attenta revisione per portare la traduzione ad una qualità accettabile, la vastità della traduzione è stata limitata al sommario del manuale, per fornire così una panoramica generale dello standard UML.

Terminato l'aspetto di traduzione del sommario UML, attraverso il quale vengono presetate le principali caratteristiche dello standard, una parte della sezione riguardante le semantiche UML viene analizzata più dettagliatamente per un'acquisizione più completa di alcuni dei metodi usati.

Il progetto propone poi l'analisi e lo sviluppo di un software secondo le metodologie UML. L'argomento proposto è la gestione dell'archivio di una università. Il sistema si occupa dell'organizzazione delle classi e dei corsi previsti.

Gli ultimi punti riguardano le conclusioni sul lavoro presentato e alcune appendici che forniscono informazioni aggiuntive su prodotti usati e altri aspetti particolari.

Il tempo previsto per il completo sviluppo del progetto è di 40 ore.

2. INTRODUZIONE ALL'INGEGNERIA DEL SOFTWARE

Prima di passare alla specificazione dell'UML si è ritenuto utile fornire una introduzione all'argomento generale che ha imposto la creazione di questo standard. Sarà qui spiegato (anche se in modo generico) cos'è l'ingegneria del software.

Scrivere software è un'attività estremamente complessa poiché complesso è il risultato che si vuole ottenere. Il numero di possibilità e alternative sul metodo di realizzazione del prodotto sono veramente elevate e risulta quindi molto difficile proporre un modello di realizzazione di tipo ingegneristico. Ciononostante, esiste una disciplina che si occupa di studiare un metodo comune per lo sviluppo corretto di software.

L'obbiettivo dell'ingegneria del software è quello di individuare un insieme di metodi di lavoro che permettano di ottenere un software di qualità. I metodi qui proposti presuppongono che il progetto da sviluppare sia di grandi o medie dimensioni, se si tratta di una piccola applicazione non si ritiene necessario sottostare a tutte le rigide regole proposte, si effettuerebbe una grande e inutile perdita di tempo.

Un prodotto software per essere considerato di qualità non deve solamente funzionare bene ma deve anche presentare delle caratteristiche aggiuntive:

Affidabilità. L'affidabilità è la corrispondenza del programma ai suoi requisiti, deve banalmente comportarsi nel modo in cui gli è stato richiesto di farlo. Le cause che possono allontanare il prodotto da questo requisito possono essere molte, in particolare risiedono in incomprensioni fra programmatori e utenti, mancanza di tempo, errori di programmazione.

Correttezza. La correttezza si pone un gradino sotto l'affidabilità ed è definita come la corrispondenza fra un programma e le sue specifiche. La differenza fra requisiti e specifiche identifica quindi anche la differenza fra affidabilità e correttezza: i requisiti sono ciò che l'utente richiede, le specifiche sono le cose che il programmatore crede che l'utente desideri, una sorta di ipotesi aggiuntive. Non sempre la descrizione degli obbiettivi del software è una cosa semplice perché l'utente non ha le conoscenze tecniche adatte per fornire delle richieste dettagliate, il programmatore dal canto suo non sempre conosce il campo specifico che il prodotto deve automatizzare, manca quindi di precisione nelle informazioni.

Robustezza. La robustezza è la capacità, da parte di un programma di comportarsi in modo affidabile anche in situazioni strane o impreviste.

Usabilità. L'usabilità è la capacità di un programma di rendersi facilmente comprensibile e utilizzabile dagli utenti finali.

Verificabilità. La verificabilità è la possibilità di verificare la correttezza del programma attraverso un algoritmo. Questo aspetto è molto importante se si considera le possibilità che permette di identificare errori, anche di importanza relativamente grande, prima che il prodotto venga consegnato all'utente.

Riusabilità. È la possibilità di riutilizzare parti del programma all'interno di un'altra applicazione. Spesso questo aspetto non viene considerato perché i programmatori vedono come unica cosa importante il problema principale, senza preoccuparsi di fare in modo che il proprio lavoro possa essere ripreso e integrato da programmi successivi.

Comprensibilità. La comprensibilità è il grado di leggibilità del codice e della documentazione del programma, in sostanza il prodotto deve fornire la possibilità di essere compreso anche a chi non lo ha sviluppato.

Con il termine ciclo di vita di un prodotto si intende identificare l'insieme di operazioni a cui il prodotto è soggetto a partire dal momento in cui viene creato fino alla sua distruzione o abbandono. Nel caso del software il ciclo di vita è costituito dalle varie fasi di sviluppo dell'applicazione. L'ingegneria del software ha identificato dei particolari modelli per lo sviluppo di un ciclo di vita, questi sono divisi in varie fasi che sono circa comuni a tutti, le differenze stanno principalmente nell'ordine con cui le fasi sono sviluppate.

Nelle varie fasi dei modelli la fase di presentazione di documentazione non viene mai presentata perché si assume come informazione implicita che la documentazione di ogni fase venga allegata alla loro composizione.

METODI DI SVILUPPO

Verranno ora esaminati alcuni dei metodi di sviluppo di software più usati. Non saranno introdotte specifiche metodologie ma verranno piuttosto analizzate le particolari caratteristiche che fanno si che un dato metodo sia racchiuso in una particolare definizione.

La principale caratteristica dei metodi di questo tipo è data dalla netta separazione fra dati (o informazioni) e funzioni (o processi).

Chi decide di adottare una di queste metodologie dedica tipicamente parte del proprio tempo per definire la struttura dei dati che l'applicazione dovrà gestire, e quindi passa a specificare, separatamente, le caratteristiche funzionali del programma. Le differenze principali fra i metodi orientati ad oggetti e i metodi strutturati stanno nelle fasi di analisi e progettazione.

Lo scopo di questa fase è quello di descrivere cosa deve fare un'applicazione, indipendentemente dal modo in cui sarà realizzata. Per lo sviluppo di questo punto i metodi strutturati propongono di realizzare un insieme di diagrammi il cui scopo è quello di descrivere le funzionalità dell'applicazione in modo preciso e formale. L'obbiettivo è quindi quello di descrivere il problema da risolvere e i suoi requisiti. Le funzionalità richieste possono anche essere espresse con annotazioni poco formali, come ad esempio un file-testo. C'è però il pericolo che questa soluzione risulti poco chiara e causi quindi incomprensioni che possono ritardare il corso delle operazioni.

I tipi di diagrammi utilizzati dai vari modelli sono molti, verranno ora presentati tre fra i più importanti e fra i più usati riguardanti i vari aspetti della progettazione.

Diagrammi ER (Entità Relazioni). Viene impiegato per rappresentare graficamente le operazioni che l'applicazione dovrà gestire. Il modello si costituisce di tre tipi fondamentali di elementi:

le entità (oggetto da considerare)

le relazioni (associazioni che legano fra loro le entità)

attributi (caratteristiche di entità o relazioni)

Spesso questo modello viene usato per descrivere strutture di database. Più in generale viene utilizzato per descrivere una qualsiasi struttura focalizzando l'attenzione sui dati e non considerando in nessun modo le operazioni che dovranno essere compiute. In questo modo il progettista si focalizza su un solo aspetto del problema diminuendo la possibilità di errore.

Diagrammi di flusso. Questo metodo viene utilizzato per rappresentare i processi, cioè le operazione di gestione dei dati. Anche qui si possono distinguere due fondamentali categorie di elementi:

i processi (operazioni effettuate)

data-store (dati richiesti dall'applicazione)

entità esterne (rappresentano qualsiasi cosa interagisca con l'applicazione dall'esterno)

Ogni collegamento fra due o più elementi rappresenta un flusso di dati.

Diagrammi di struttura. Hanno il compito di descrivere come devono essere soddisfatti i requisiti evidenziati durante le fasi di analisi, fornendo una descrizione esatta di come dovrà lavorare l'applicazione. In questo tipo di diagrammi vengono messi in relazione fra loro degli elementi chiamati moduli, che rappresentano le funzioni o le procedure in cui l'applicazione si scompone.

Uno dei principali limiti dei metodi strutturati è costituito dalla differenza di notazioni utilizzata all'interno delle varie fasi. Una fase della progettazione consiste infatti nella traduzione di questi diagrammi, tale operazione non è però determinata da precisi standard ed è quindi demandata in buona parte all'estro e all'esperienza del progettista.

I metodi orientati ad oggetti mirano a superare questo limite, definendo il problema attraverso dei basilari concetti di classe, oggetto, ereditarietà. In questo modo ciò che distingue maggiormente una fase da un'altra non è la notazione utilizzata, quanto i tipi di classi e oggetti presi in considerazione. Nella fase di analisi si provvederà a descrivere gli oggetti che identificano la struttura del problema, la cui natura sarà comprensibile anche all'utente, nella fase di progettazione invece saranno considerati quegli oggetti che racchiudono informazioni relative alla struttura di soluzione del problema.

Ovviamente ogni scelta precipitosa ed effettuata a priori verso un particolare modello risulterà errata. La scelta del metodo da utilizzare dipende da molti fattori, tra cui il tipo di linguaggio da utilizzare, il tipo di applicazione da sviluppare e anche dal gusto e dalla cultura dei progettisti.

In ogni caso il pregio maggiore dell'utilizzo di questi metodi è quello di costringere ad essere metodici, evitando quindi errori di disattenzione, imprecisione, fretta.

INTRODUZIONE ALL'UML E SUOI OBBIETTIVI

La notazione UML (Unified Modelling Language) è una delle più diffuse per quanto riguarda la programmazione orientata ad oggetti.

UML è però spesso erroneamente considerato come metodo di progettazione. Una notazione è solo un formalismo atto a rappresentare delle informazioni, un metodo è qualcosa di più in quanto indica come utilizzare questi formalismi per sviluppare l'analisi, la progettazione, lo sviluppo, la manutenzione di un'applicazione.

UML è (come dice il nome stesso) un modello unificato di altre notazioni prima esistenti, principalmente tre, presentate da tre personalità molto importanti nell'ambito delle metodologie di sviluppo object-oriented: Booch, Rumbaugh, Jacobson.

In realtà le intenzioni iniziali degli autori erano quelle di proporre un metodo, e non solo un modello di rappresentazione. Poiché però il compito di definire un metodo di sviluppo universalmente adattabile a tutte le categorie applicative esistenti sarebbe stato estremamente difficile, è stato successivamente deciso di limitare la portata del progetto, aumentando la possibilità di imporsi come standard.

La complessità di UML può essere considerata di fatto una delle maggiori limitazioni al suo uso reale. Essa deriva in parte dalla fusione delle tre notazioni originarie, in parte dall'ambizioso obbiettivo che si propone di riuscire a modellare un qualsiasi sistema object-oriented. Come sempre la ragione sta un po' da entrambe le parti di quelli che sostengono l'utilità e i vantaggi di UML e da chi lo considera di eccessiva complessità e quindi non applicabile in un ampio campo reale. Sicuramente però viene universalmente riconosciuto che UML contribuisce a gestire i gruppi di lavoro e a creare una documentazione che possa essere facilmente compresa e utilizzata anche da persone che dovessero cominciare al lavorare al progetto solo in un secondo tempo.

LO STANDARD UML

In questa parte del progetto verrà presentato e relazionato il documento UML nella specificità dei metodi e della sua organizzazione. Nell'intento di fornire una visuale completa della costituzione del manuale, senza entrare in specifici particolari, che in questa sede sono stati ritenuti superflui, verrà ora presentata la traduzione completa del sommario UML. Questa parte del manuale fornisce una generale presentazione utile all'utente per orientarsi in particolari aspetti interessati o solamente per una generale comprensione dell'argomento trattato.

3.1 CONTENUTI DEL DOCUMENTO SOMMARIO UML

Lo sviluppo di questo punto, riportando interamente la traduzione del documento Sommario rispetterà la forma del testo originario, la sequenza dei punti sviluppati si riferisce dunque al documento analizzato secondo l'indice qui proposto.

INDICE SOMMARIO

PREFAZIONE

PUBBLICO INTERNAZIONALE

MOTIVAZIONE PER DEFINIRE L'UML

2,1 PERCHE' MODELLIAMO

2,2 TENDENZE DELL'INDUSTRIA DEL SOFTWARE

2,3 PRIORITA  DI CONVERGENZA DELL'INDUSTRIA

OBBIETTIVI DELL'UML

AMBITO DI UML

PRODOTTI PRIMARI DI UML

FUORI DALL'AMBITO DI UML

CONFRONTO DI UML CON I LINGUAGGI DI MODELLAZIONE DI BOOCH, OMT, OOSE, E ALTRI METODI

NUOVE CARATTERISTICHE DI UML

PASSATO, PRESENTE E FUTURO DI UML

UML 0.8 - 0.91

UML 3.1 CON I PARTNERS UML

IL PRESENTE DI UML

IL FUTURO DI UML

RINGRAZIAMENTI

REFERENZE

PREFAZIONE

L' »Unified Modelling Language» (UML) è un linguaggio usato per specificare, visualizzare, costruire e documentare i manufatti di sistemi software, come la modellistica nel campo degli affari ed altri sistemi non-software.

L'UML rappresenta una raccolta delle migliori pratiche dell'ingegneria che sono state verificate con successo nella modellistica di grandi e complessi sistemi.

La definizione dell'UML consiste nei seguenti documenti:

Semantiche dell'UML. Definisce le ricche semantiche e la sintassi espressiva dell'«Unified Modelling Language». L'UML è strutturato e organizzato in pacchetti. Attraverso ciascun pacchetto gli elementi del modello sono definiti in sessioni basate sulla loro sintassi astratta (usando la notazione a diagrammi di classe UML), modulazione delle regole (usando testi e costrizioni delle espressioni del linguaggio), e semantiche (usando un testo preciso). Due appendici sono incluse: Glossario UML ed Elementi Standard.

Notazione Guida dell'UML Definisce nozioni e provvede alla presentazione degli esempi. La notazione UML rappresenta la sintassi grafica per esprimere le semantiche descritte dal metamodello UML.

Estensioni dell'UML per la Progettazione ad Oggetti nell'Ingegneria del Software ed estensione UML per Modellazione nel campo Commerciale. Questa sezione include processi e estensioni di domini specifici all'UML, sessioni dei suoi meccanismi estesi e icone del diagramma processo-specifiche.

L'UML usa OCL, definito separatamente nel documento Object Constraint Language Specification (Specificazione dell' OCL).

PUBBLICO INTENZIONALE

Questo documento è inteso primariamente come una precisa e consistente definizione delle semantiche e delle notazioni UML. I destinatari primari di questo documento sono l'Object Management Group (Gruppo di Gestione dell'Oggetto), organizzazioni di produzione degli standard, autori di libri, e costruttori di dispositivi. I progettisti si presume abbiano familiarità con metodi di analisi orientati ad oggetti e metodi di disegno. Questi documenti non sono scritti come testo introduttivo per la costruzione di modelli a oggetti di sistemi complessi, ma possono essere usati in congiunzione con altro materiale o istruzioni. Questa collezione di documenti diventerà più accessibile a un pubblico più ampio quando manuali addizionali, corsi di formazione e dispositivi che adottano le metodologie UML diverranno disponibili.

MOTIVAZIONE PER DEFINIRE L'UML

Questa sezione descrive alcuni fattori che motivano l'UML. Discutiamo perché la modellistica è essenziale, accentua alcune tendenze chiave nell'industria del software, e descrive i problemi causati dalla divergenza degli approcci della modellistica.

PERCHE' MODELLIAMO

Sviluppando un modello per un sistema software dell'industriale pesante l'importanza della sua costruzione o del suo rinnovamento è essenziale. Dei buoni modelli sono essenziali per la comunicazione fra squadre di progettazione e per assicurare una buona costruzione architettonica. Costruiamo modelli di sistemi complessi perché non possiamo comprendere il sistema nella sua globalità. Con l'aumentare della complessità dei sistemi, delle buone tecniche di modellistica diventano sempre più importanti. Ci sono molti fattori addizionali che determinano il successo di un progetto, ma avere un standard rigido della lingua della modellistica è un aspetto essenziale. Una linguaggio della modellistica deve includere:

Elementi del modello - concetti e semantiche fondamentali della modellistica

Notazione- traduzione visuale di elementi del modello

Orientamenti- idiomi di uso nel mestiere

Di fronte a sistemi sempre più complessi, visualizzazione e modellistica divengono essenziali. UML è una definita ed estesamente riconosciuta risposta a quello di cui si ha bisogno. E' la modellistica visuale la lingua scelta per la costruzione di sistemi orientati ad oggetti e basati su componenti.

TENDENZE DELL'INDUSTRIA nel SOFTWARE

Con l'aumento per molte compagnie del valore strategico del software, l'industria cerca tecniche per automatizzare la produzione di software. Noi cerchiamo tecniche per migliorare qualità e ridurre costi e tempo di realizzazione. Queste tecniche includono la tecnologia del componente, la programmazione visuale, modelli, e strutture. Cerchiamo anche tecniche per dirigere la complessità di sistemi al loro aumento di scopi e scala. In particolare, riconosciamo il bisogno di risolvere ricorrenti problemi architettonici, come la distribuzione fisica, accessi concorrenti, duplicazioni, sicurezza, bilanciamento del carico di lavoro e tolleranza del difetto. La sviluppo per una scala mondiale semplifica alcune cose, ma esalta questi problemi architettonici.

La complessità varierà in base al dominio dell'applicazione e alla fase del processo. Uno delle motivazioni chiave nelle menti degli sviluppatori dell'UML era quella di creare una collezione di semantiche e notazioni che indirizzi adeguatamente tutte le scale di complessità architettonica, attraverso tutti i domini.

PRIORITA' DI CONVERGENZA dell'INDUSTRIA

Prima dell'UML non c'era nessuna lingua che definisse chiaramente la modellistica. Gli utenti dovevano scegliere fra molti simili linguaggi, caratterizzati da differenze nel loro potere espressivo.

La maggior parte delle lingue della modellistica hanno condiviso una collezione di concetti comunemente accettati, espressi in modo leggermente diverso dai vari linguaggi. Questa mancanza di un comune accordo fra i metodi ha scoraggiato nuovi utenti da entrare nel mercato dell'OO (Object Oriented) e da produrre modellistica OO, comportando così un'espansione non consistente delle possibilità della modellazione. Gli utenti hanno desiderato che l'industria adotti un linguaggio per la modellistica largamente supportato e adatto per un uso generale. Hanno voluto una lingua franca per la modellistica.

Alcuni venditori sono stati scoraggiati da entrare area della modellistica OO a causa del bisogno di sostenere molti simili, ma leggermente differenti, linguaggi. In particolare, l'approvvigionamento di dispositivi aggiuntivi è stato soppresso perché i piccoli venditori non potevano permettersi di sostenere molte differenti configurazioni dei dispositivi di interfaccia. E' importante per l'intera industria OO incoraggiare prodotti e venditori, come prodotti che rispondono alle necessità di gruppi specializzati.

Il costo continuo dell'uso e del supportare molti linguaggi per la modellistica ha motivato molte compagnie a produrre o usare la tecnologia dell'OO per sostenere lo sviluppo dell'UML.

Se l'UML non garantisce il successo del progetto, migliora però molte cose. Per esempio esso abbassa significativamente i costi continui di aggiornamento quando cambiano i progetti o le organizzazioni. Provvede all'opportunità di una nuova integrazione tra prodotti, processi, e domini. E, cosa più importante, abilita chi sviluppa a focalizzare il lavoro sul valore del prodotto.

OBBIETTIVI DELL'UML

Le mete primarie nel disegno dell'UML erano le seguenti:

Fornire agli utenti un linguaggio per la modellistica espressiva visuale pronto per l'uso, per permettergli di sviluppare e scambiare modelli significativi.

Fornire estensibilità e meccanismi specializzati per estendere i concetti primari.

Essere indipendente dai diversi linguaggi di programmazione e dai processi di sviluppo.

Fornire una base formale per la comprensione del linguaggio della modellistica.

Incoraggiare la crescita del mercato dei prodotti dell'OO.

Sostenere i concetti dello sviluppo ad alto livello come collaborazioni, strutture, modelli, e componenti.

Utilizzare le migliori pratiche integrate.

Queste mete sono discusse in seguito.

Fornisce agli utenti un pronto uso della lingua della modellistica espressiva visuale per permettere loro di sviluppare e scambiare modelli significativi. E' importante che l'OOAD standard sostenga un linguaggio che possa essere usato fuori dai normali contesti per eseguire i compiti della modellistica. Se lo standard provvede solamente ad una descrizione meta-meta che richiede l'assemblamento di un gruppo particolare di concetti della modellistica, allora non raggiungerà lo scopo di permettere agli utenti di scambiare modelli senza perdere informazioni o senza imporre eccessivo lavoro per progettare i loro modelli in forma astratta. L'UML consolida una serie di concetti basilari della modellistica che generalmente sono accettati da molti dei metodi e dei prodotti usati. Questi concetti sono necessari nella maggioranza delle grandi applicazioni, benché non ogni concetto sia richiesto in ogni parte di ogni applicazione. Specificare un meta-metalivello configurato per dei concetti non è sufficiente per i modelli utente, perché i concetti devono essere fatti concretamente per una realizzazione nella modellistica. Se i concetti in diverse aree della domanda sono sostanzialmente diversi, allora un tale approccio può essere utilizzabile, ma i concetti centrali richiesti dalla maggior parte delle applicazioni sono simili dovrebbero perciò essere sostenuti direttamente dallo standard.

Fornire estensibilità e meccanismi specializzati per estendere i concetti primari. Ci aspettiamo che l'UML sarà adattato quando saranno scoperte nuove necessità e nuovi domini specifici. Allo stesso tempo, non vogliamo forzare i concetti basilari comuni ad essere ridefiniti per ciascuna area. Perciò crediamo che l'estensione dei meccanismi debba sostenere deviazioni dal caso comune, non perfezionare il centro dei concetti stessi dell'OOAD. I concetti centrali non dovrebbero essere cambiati più del necessario. Gli utenti hanno bisogno di poter:

costruire modelli usando i concetti basilari senza usare i meccanismi per la maggior parte delle normali applicazioni;

aggiungere nuovi concetti e notazioni per problemi non inclusi nel centro;

3)scegliere fra interpretazioni varie di concetti esistenti, quando c'è un contesto poco chiaro;

specializzare i concetti, notazioni, e costrizioni per particolari domini dell'applicazione

Essere indipendente da particolari linguaggi di programmazione e processi d isviluppo. L'UML deve e può sostenere tutte lingue della programmazione più usate. Deve e può anche sostenere i metodi e i processi vari dei modelli di costruzione senza eccessiva difficoltà.

Provvedere una base formale per la comprensione della lingua della modellistica. Perché gli utenti usino formalità come aiuto nella comprensione del linguaggio, esse devono essere precise ed accessibili; una mancanza di estensione adeguata di uno dei due requisiti danneggia la sua utilità. I formalismi non devono richiedere livelli eccessivi di vie indirette o stratificazioni, usando notazioni matematiche a basso-livello lontane dal dominio di modellazione o definizioni operative (equivalenti a programmare una realizzazione). L'UML provvede una definizione formale della configurazione statica del modello usando un metamodello descritto in "UML class diagrams". Questo è un popolare ed estesamente accettato approccio formale per specificare la configurazione di un modello e direttamente portare alla sua realizzazione. UML esprime costrizioni di forma in un preciso inglese e in espressioni della Object Constraint Language. UML esprime il significato operativo della maggior parte delle costruizioni con una lingua di uso corrente. Il pieno approccio formale preso da specifici linguaggi come Algol-68 non era sufficentemente accessibile per un uso pratico.

Incoraggiare la crescita del mercato di prodotti dell'OO. Abilitando i venditori a sostenere un linguaggio standard per la modellistica usato dalla maggior parte di utenti e prodotti. Mentre i venditori ancora possono aggiungere valore alle realizzazioni dei loro dispositivi, permettere l'interoperabilità è essenziale. L'interoperabilità richiede che i modelli possano essere scambiati fra utenti e dispositivi senza perdita di informazioni. Questo può accadere solamente se i dispositivi riconoscono la configurazione e il significato di tutti i concetti attinenti. Usando un meta-livello più alto nessuna soluzione è inclusa nello standard a meno del rilevamento dei concetti del livello-utente.

Sopportare concetti di sviluppo di più alto livello come collaborazioni, strutture, modelli, e componenti. Definire chiaramente semantiche di questi concetti è essenziale per acquisire il pieno beneficio dell'OO. Definre questi concetti nel contesto di un linguaggio della modellistica è un contributo dell'UML.

Integrare le migliori pratiche. Una motivazione chiave dello sviluppo dell'UML è stata integrare le migliori pratiche dell'industria, circondando  estesamente le varie viste basate su livelli di astrazione, domini, architetture, cicli di vita, tecnologie della realizzazione, etc. L'UML è davvero tale integrazione delle migliori pratiche.

AMBITO DI UML

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», 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 rende 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.

PRODOTTI PRIMARI DI UML

Quali sono i prodotti primari di UML? Si può rispondere a questa domanda da due diversi punti di vista: con la definizione di UML e come UML viene utilizzato per realizzare i prodotti di progetto.

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.

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.

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.

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.

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:

Ogni sistema complesso può venire descritto meglio grazie ad un insieme di viste logiche (view) di un modello, quasi indipendenti tra loro; un'unica vista complessiva non è sufficiente.

Ogni modello può venire rappresentato a diversi livelli di dettaglio.

I modelli migliori sono strettamente legati alla realtà.

In termini di viste logiche di un modello, UML prevede la definizione dei seguenti diagrammi:

diagramma dei casi d'uso (use case diagram)

diagramma delle classi (class diagram)

diagrammi dei comportamenti (behavior diagrams) :

diagramma di transizioni di stato (state diagram)

diagramma delle attività (activity diagram)

diagramma di sequenza (sequence diagram)

diagramma di collaborazione (collaboration diagram)

diagrammi di implementazione (implementation diagrams)

diagramma delle componenti (component diagram)

diagramma di allocazione (deployment diagram)

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.

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.

FUORI DALL'AMBITO DI UML

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.

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'invio 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.

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:

fornisce linee guida sulla sequenza delle attività di un gruppo di lavoro

specifica quali prodotti devono essere sviluppati nelle varie fasi

guida i compiti dei singoli individui e del gruppo

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.3CONFRONTO 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.

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:

stereotipi

responsabilità

meccanismi di estensione: stereotipi, tagged values, constraints

threads e processi

distribuzione e concorrenza (ad esempio per modellare ActiveX/DCOM and CORBA)

patterns/collaborazioni

diagrammi delle attività (per il business process reengineering)

separazione chiara di tipo, classe, istanza

affinamenti (per gestire i legami tra diversi livelli di astrazione)

interfaccie e componenti

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.

PASSATO, PRESENTE E FUTURO DI UML

UML 0.8 - 0.91

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.

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:

Modellizzare sistemi (non solo software) utilizzando concetti object-oriented

Stabilire un legame (coupling) esplicito con prodotti concettuali e prodotti eseguibili

Indirizzare gli aspetti di scalabilità inerenti nei sistemi complessi e mission-critical

Creare un linguaggio di modellazione utilizzabile sia da esseri umani che dalle macchine .

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.

UML 1.0 CON I PARTNER UML

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.

IL PRESENTE DI UML

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.

IL FUTURO DI UML

Nel momento in cui scriviamo queste cose, le prossime tappe pianificate sono:

I partner UML sottoporranno l'insieme della documentazione UML all'OMG, il 16 gennaio 1997.

I partner UML risponderanno ai feedback di OMG e di tutti gli interessati durante la prima metà del 1997.

OMG deciderà sull'adozione di UML come standard verso la metà del 1997.

I metodologi di UML, e altri autori, pubblicheranno materiale addizionale e libri nel corso del 1997.

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 versione 1.0 di UML è 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.

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 costruttivi 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.

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.

RINGRAZIAMENTI

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.

Grady Booch, egb@rational.com

Ivar Jacobson, ivar@rational.com

Jim Rumbaugh, rumbaugh@rational.com

Gruppo di lavoro primario per UML 1.0

Digital Equipment

Paul Patrick, patrick@send.enet.dec.com

Jim Rye, rye@send.enet.dec.com

Hewlett-Packard

Martin Griss, griss@hpl.hp.com

Reed Letsinger, letsinger@hpl.hp.com

i-Logix

Eran Gery, erang@ilogix.co.il

Prof. David Harel, harel@wisdom.weizmann.ac.il

James Odell

James Odell, 71051.1733@compuserve.com

MCI Systemhouse

Cris Kobryn, ckobryn@acm.org

Joaquin Miller, miller@shl.com

Microsoft

Philip A. Bernstein, philbe@microsoft.com

Rick Hargrove, rickha@microsoft.com

Andy Moss, andymo@microsoft.com

Oracle

Guus Ramackers, gramacke@uk.oracle.com

Rational Software

Ed Eykholt, eykholt@rational.com

Grant Larsen, gjl@rational.com

Dave Tropeano, davet@rational.com

Texas Instruments

John Cheesman, j-cheesman@ti.com

Bob Hodges, bhodges@ti.com

Glenn Hollowell, glenn@ti.com

Keith Short, keiths@ti.com

Unisys

Sridhar Iyengar, Sridhar.Iyengar@mv.unisys.com

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.

BIBLIOGRAFIA

[Bock/Odell 94] C. Bock and J. Odell, «A Foundation For Composition,» Journal of

Object-oriented Programming, Ottobre 1994.

Language User Guide, ISBN: 0-201-57168-4, Addison Wesley, est.

Pubblicazione Dicembre 1997. Vedi www.awl.com/cp/uml/uml.html.

[Cook] S. Cook and J. Daniels, Designing Object Systems: Object-oriented

Modelling with Syntropy, Prentice-Hall Object-Oriented Series, 1994.

[D'Souza 1997°] D. D'Souza and A. Wills, «Input for the OMG Submission,»

www.iconcomp.com/catalysis

[D'Souza 1997b] D. D'Souza and A. Wills, «Catalysis: Component and Framework based

development» www.iconcomp.com/catalysis

Modeling Language, ISBN 0-201-32563-2, Addison-Wesely, 1997.

https://www.awl.com/cp/uml/uml.html

[Griss96] M. Griss, Domain Engineering And Variability In The Reuse-Driven

Software Engineering Business. Object Magazine. Dicembre 1996. (See

www.hpl.hp.com/reuse)

[Harel 87] D. Harel, «Statecharts: A Visual Formalism for Complex Systems,»

Science of Computer Programming 8 (1987), 231-274.

[Harel 96°] D. Harel and E. Gery, «Executable Object Modeling with Statecharts,»

Proc. 18th Int. Conf. Soft. Eng., Berlin, IEEE Press, March, 1996, pp.

[Harel 96b] D. Harel and A. Naamad, «The STATEMATE Semantics of Statecharts,»

ACM Trans. Soft. Eng. Method 5:4 (Oct. 1996).

Development Process, ISBN: 0-201-57169-2, Addison Wesley est.

pubblicazione Dicembre 1997. Vedi www.awl.com/cp/uml/uml.html e

«Rational Objectory Process» su www.rational.com.

[Malan96] R. Malan, D. Coleman, R. Letsinger et al, The Next Generation of Fusion,

Fusion Newsletter, Ottobre 1996. (Vedi www.hpl.hp.com/fusion.)

[Martin/Odell 95] J. Martin and J. Odell, Object-oriented Methods, A Foundation, ISBN:

[Ramackers95] Ramackers, G. and Clegg, D., «Object Business Modelling, requirements

and approach» in Sutherland, J. and Patel, D. (eds.), Proceedings of the

OOPSLA95 workshop on Business Object Design and Implementation,

Springer Verlag, publication pending.

[Ramackers96] Ramackers, G. and Clegg, D., «Extended Use Cases and Business Objects

for BPR,» ObjectWorld UK '96, London, Giugno 18-21, 1996.

[Rumbaugh et al.] Jim Rumbaugh, Ivar Jacobson, and Grady Booch, Unified Modeling

Language Reference Manual, ISBN: 0-201-30998-X, Addison Wesley,

Questo documento è stato pubblicato nel nel Gennaio 1997. Gli ulteriori sviluppi dell'UML sono elencati nell'appendice UML Storia e Cronaca oppure possono essere reperiti nel sito internet www.awl.com/cp/uml/uml.html

L'UML in seguito all'approvazione come standard da parte dell'OMG parteciperà al simposio dell'OO dell'Ottobre 1999.

Dopo aver preso visione della generale costituzione dell'UML si passerà ora alla presentazione di un particolare aspetto del manuale: Le semantiche dell'UML.

Questo documento è inteso primariamente a fornire una precisa e comprensibile specificazione della costruzione delle semantiche dell'UML. Esse riguardano modelli strutturati e modelli orientati ad oggetti, ai quali si è già accennato nella parte riguardante l'introduzione all'ingegneria del software (vedi punto .2).

Sebbene il documento sia stato pensato per lettori con una preparazione avanzata nel campo specifico, esso si presenta di agile comprensione anche ad un pubblico meno esperto. La struttura dell'intero documento, come del linguaggio, si basa su elementari concetti per la costruzione e la estensione delle semantiche.

Il documento viene integrato nel manuale dal documento «UML Notation» dove sono specificate tutte le notazioni dei modelli che sono interessati dalle semantiche. «UML Notation» include supporti per un vasto range di tecniche visuali, descrive cioè tutti i diagrammi usati in uno sviluppo con UML, con le relative semantiche rilevanti per ogni diagramma.

L'architettura dell'UML è basata su un metamodello composto da quattro strati: oggetti utente, modelli, metamodelli, meta-metamodelli (una più ampia descrizione dell'architettura dell'UML è contenuta nell'apposita sezione del manuale, per una maggiore comprensione si consiglia inoltre di consultare il glossario per i termini specifici).

Il metamodello dell'UML è un modello logico. Il vantaggio di questa scelta (rispetto a quella di un modello fisico) riguarda le sue semantiche dichiarative e dettagli di implementazione.

Anche UML è costruito attraverso gli strati di un metamodello logico. Il linguaggio è diviso in alcuni pacchetti logici: Fondazione, Elementi di Comportamento, Meccanismi Generali.

Il metamodello è descritto in modo semiformale usando tre viste:

Sintassi astratta

Fornita attraverso un modello descritto in un parte separata dell'UML, caratterizzata da un diagramma di classe e un supporto descrittivo.

Regole di formazione

Fornite usando un linguaggio formale (Object Constraint Language) e un supporto descrittivo.

Semantiche

Fornite attraverso una parte descrittiva che può però includere alcune annotazioni addizionali, dipendenti dalla parte del modello che viene descritta.

Altre informazioni sono reperibili nella sezione «Language Formalism».

Nel sommario, il metamodello UML è stato descritto come una composizione di parti descrittive, notazioni grafiche, notazioni in linguaggi formali. È stato riconosciuto dai costruttori di UML come la presentazione attraverso un metamodello possa imporre dei limiti teorici a cosa un progettista può esprimere, ma l'esperienza e risultati ottenuti utilizzando dei metamodelli ha portato a considerare questi come una giusta collocazione intermedia fra la possibilità di espressione e la leggibilità del progetto.

Organizzazione del documento

Parte1: Background.

Espone come l'UML è strutturato. La sezione riguardante l'architettura descrive la struttura del linguaggio e la sua costruzione a quattro strati di un metamodello. La sezione di specificazione del linguaggio descrive invece come il linguaggio viene rigorosamente definito usando delle viste multiple.

Parte 2: Fondamenti.

Definisce le infrastrutture necessarie per l'UML, i pacchetti usati. È decomposta in alcuni sub-pacchetti: pacchetti Core (che specificano i concetti elementari per un datamodello e forniscono la definizione di alcune sue parti costituenti, come le metaclassi, le metaassociazioni, i metaattributi), i pacchetti di Elementi Ausiliari (che definiscono le strutture addizionali che estendono i pacchetti Core per supportare concetti avanzati come dipendenze, strutture fisiche, elementi di viste), i pacchetti di Estensione dei Meccanismi (che specificano come gli elementi dei modelli sono adattati ed estesi con le nuove semantiche), i pacchetti riguardanti i Tipi di Dati (che definiscono le strutture basilari di dati del linguaggio).

Parte 3: Elementi Relazionali.

Definisce la struttura per la modellazione in UML. Sono forniti dei pacchetti di Elementi Relazionali che si dividono in: Comuni Relazioni (che specificano il nucleo dei concetti richiesti da questa sezione), Collaborazioni (che specificano un contesto per usare i modelli per lo sviluppo di un particolare task), Use Case (che specificano come usare attori e use-cases).

Parte 4: Meccanismi Generali.

Definisce meccanismi generalmente applicabili ai modelli. Questa versione dell'UML contiene un pacchetto per i Meccanismi Generali: Model Management. Il pacchetto Model Management specifica come gli elementi sono organizza all'interno dei modelli, i pacchetti e i sistemi.

I seguenti documenti sono importanti per comprendere la fattezza del metamodello UML e come esso viene usato:

UML Summary: fornisce un'introduzione all'UML, discutendo el sue innovazioni e la sua storia.

UML Notation Guide: definisce la sintassi grafica per l'espressione delle semantiche presentate nel metamodello UML.

OCLS (Object Constraint Language Specification): descrive la sintassi dell'OCL (vedi appendice OCL), le sue semantiche e la grammatica.

UML COBRAfacility Interface Definition: specifica l'interfaccia di dispositivi usando COBRA IDL.

UML Proposal Summary: riassume le proposte dell'OMG e discute le relazioni fra UML e altre tecnologie.

A causa del tempo limitato concesso per lo sviluppo di questa relazione, solo un punto di questo documento verrà relazionato per intero, per un ulteriore approfondimento degli altri si propone la consultazione del manuale dell'UML.

La parte in questione è la prima del documento («Background»). La scelta è stata orientata in questo modo per fornire una più dettagliata spiegazione di come è costituito il manuale e del significato di metamodello , che può risultare di difficile comprensione.

PARTE 1 BACKGROUND

Come già detto, la parte Background descrive come UML è strutturato. È composta da due sezioni:

Language Architecture: descrive le strutture del linguaggio e fornisce una definizione dei quattro strati che compongono il metamodello del manuale, ai quali si è accennato in precedenza.

Language Formalism: descrive come il linguaggio è definito usando tre viste complementari.

LANGUAGE ARCHITECTURE

Il metamodello definisce in modo completo le semantiche per la rappresentazione di modelli orientati ad oggetti usando UML. Esso è uno degli strati dell'architettura a quattro strati del metamodelllo. Vista la complessità dello strato del metamodello esso è spesso decomposto in pacchetti logici. Questi permettono una maggiore maneggevolezza del linguaggio. Di seguito verrà descritto l'architettura del metamodelllo a quattro strati dell'UML e la struttura dei suoi pacchetti.

FOUR-LAYER METAMODEL ARCHITECTURE

Il metamodello UML è definito come uno degli strati di una architettura a quattro strati di un metamodello. Questa architettura è un'infrastruttura per la definizione delle precise semantiche richieste da modelli complessi. Altri vantaggi sono poi associati a questo tipo di approccio:

esso convalida il nucleo della struttura per una successiva applicazione anche a successivi strati del modello

esso provvede ad una architettura di base facilmente espandibile in future revisioni dei metamodelli UML

esso fornisce una architettura di base che permette di allineare UML altri standard basati su architetture di metamodelli a quattro strati (es. OMG Meta-Object Facility, CDIF).

Generalmente i framework accettati per la modellazione sono divisi nei quattro strati di cui già si è accennato sopra. Una spiegazione sommaria dei loro compiti è fornita di seguito.

Lo strato meta-metamodello definisce la base dell'architettura di un metamodello. La responsabilità primaria di questo strato è quella di definire un linguaggio per la specificazione di un metamodello. Un metamodello definisce un modello ad un più alto livello di astrazione, e usualmente è più compatto del metamodello che descrive. Un meta-metamodello può definire più metamodelli a ciascuno dei quali può essere associato più di un meta-metamodello. Generalmente si richiede che i metamodelli e i meta-metamodelli relazionati condividano lo stesso disegno logico e la stessa struttura. Ma ogni strato deve contemporaneamente mantenere la sua integrità di struttura. Esempi di meta-metaoggetti nello strato meta-metamodelling sono: MetaClassi, MetaAttributi, MetaOperazioni.

Un metamodello è un'istanza di un meta-metamodello. La primaria responsabilità di questo strato è quella di definire un linguaggio per la specificazione di modelli. Tipicamente i metamodelli sono più elaborati dei meta-metamodelli che li descrivono, in particolare quando definiscono semantiche dinamiche. Esempi di oggetti nello strato metamodelling sono: Classi, Attributi, Operazioni, Componenti.

Un modello è un'istanza di un metamodello. La primaria responsabilità è quella di definire un linguaggio che descriva un dominio di informazioni. Esempi di oggetti nello strato modelling sono: StockShare, askPrice, sellLimitOrder, StockQuoteServer.

Gli oggetti utente sono delle istanze di un modello. La primaria responsabilità di questo strato è quella di descrivere un dominio specifico di informazioni. Esempi di oggetti nello strato objects sono: <Acme_Software_Share_98789>, 654.56, sell_limit_order, <Stock_Quote_Svr_32123>.

Il metamodello UML è stato architettato in modo corrispondente con l'OMG Meta Object Facility (MOF) meta-metamodello. Le relazioni sono ampiamente descritte in un'appendice del manuale UML.

FORMALISMO DEL LINGUAGGIO

Questa sezione contiene una descrizione delle tecniche usate per descrivere UML. La specificazione adatta tecniche formali per il miglioramento della precisione mantenendo la leggibilità. La tecnica descrive il metamodello UML in tre divesre viste, usando rappresentazioni grafiche e parti descrittive. I vantaggi dell'adattare tecniche formali sono:

la correttezza della descrizione viene migliorata

ambiguità e inconsistenze vengono sensibilmente ridotte

l'architettura del metamodello è convalidata da una tecnica complementare

la leggibilità della descrizione è aumentata.

È importante sottolineare che la descrizione fornita in questa parte del documento non è una completa descrizione formale del linguaggio, una soluzione diversa andrebbe però a compromettere la chiarezza del paragrafo.

LIVELLI DI FORMALISMO

Una tecnica comune per la specificazione dei linguaggi definisce inizialmente la sintassi di un linguaggio descrive poi le sue semantiche statiche e dinamiche. La sintassi definisce la costruzione del linguaggio, spesso, in particolare se il linguaggio ha una sintassi grafica, è importante definire la sintassi in un modo differente dalle notazioni. La sintassi concreta sarà poi definita mappando le notazioni sulla sintassi astratta. La sintassi di UML è descritta nella sezione intitolata Abstract Sintax.

Le semantiche statiche del linguaggio definiscono come un'istanza di una costruzione può essere connessa con altre istanze, le semantiche dinamiche definiscono invece il significato di una costruzione appropriata. Le semantiche statiche sono descritte più ampiamente nella sezione Well-Formedness Rules Le semantiche dinamiche sono descritte nella sezione intitolata Semantics. In alcuni casi parti delle semantiche statiche sono descritte nella sezione Semantics.

Nella costruzione di UML sono stati usati per le specificazioni di linguaggi differenti tipi di tecniche descrittive, che, completandosi a vicenda, hanno contribuito a fornire chiarezza al linguaggio.

SPECIFICAZIONE DELLA STRUTTURA DEI PACCHETTI

Questo documento ha una sezione per ogni pacchetto del metamodello UML, ogni sezione è composta da queste sottosezioni:

Sintassi Astratta. La sintassi astratta è presentata in un diagramma che evidenzia le metaclassi che definiscono la costruzione e le loro relazioni. Il diagramma presenta anche alcune regole di forma, principalmente le richieste di molteplicità delle relazioni.

Regole Formali. Le semantiche statiche di ogni costruzione in UML, sono definite come una serie di costanti di un'istanza di una metaclasse. Ogni costante è definita da una istruzione OCL assieme ad una parte descrittiva.

Semantiche. Il significato delle costruzioni sono definite usando una parte descrittiva. Le costruzioni sono raggruppate in sessioni logiche, la definizione riguarda le sessioni logiche e non scende nei particolari di ogni costruzione.

Elementi Standard. Stereotipi delle meataclassi sono definiti precedentemente nella sessione, sono descritti con un piccolo paragrafo. Regole di forma per gli stereotipi sono descritte nello stesso modo. Altri tipi di elementi standard sono definiti nelle appendici degli Elementi Standard.

Note. Questa subsessione contiene regole per le decisioni sui metamodelli, per l'uso delle costruzioni, esempi, tutti argomentati da un paragrafo descrittivo.

4. PROPOSTA DI UN PROGETTO SECONDO LO STANDARD

In questa parte del progetto verranno illustrate le tecniche usate dallo standard UML per lo sviluppo di software attraverso un esempio pratico preso dal sito della Rational, una delle società che ha contribuito alla costruzione, allo sviluppo e all'imposizione come standard del manuale UML.

Il prodotto utilizzato è quello distribuito dalla società Rational, il Rational Rose VB Professional. Altri prodotti simili a questo sono disponibili sul mercato. Molti linguaggi offrono infatti la possibilità di uno sviluppo guidato di sistemi software. Le tendenze dell'industria del software sono principalmente orientate verso questo tipo di prodotti che permette un notevole risparmio di tempo e, cosa più importante, permette lo sviluppo di software indirizzando i metodi verso uno standard preciso e comune a tutti i programmi, lo standard è ovviamente l'UML (informazioni su prodotti e sulle aziende che li distribuiscono sono reperibile nell'appendice Strumenti basati sull'UML).

L'esempio qui considerato permette di testare il drive Rational Rose VB Professional costruendo un prodotto software che si incarichi della gestione di alcuni corsi di insegnamento tenuti presso una università (nell'illustrazione e nella descrizione dello sviluppo si è scelto per comodità esplicativa di mantenere i termini in lingua inglese usati dallo standard per le entità e le form utilizzate).

Prima di entrare nella descrizione dei metodi è utile stabilire quali sono i requisiti necessari per lo sviluppo:

Rational Rose 98 Enterprise o Rational Rose 98 VB Professional: per lo sviluppo della struttura del prodotto.

Visual Basic 5.0: per lo sviluppo del codice del prodotto. La scelta del linguaggio di programmazione può essere effettuata in varie direzioni offerte dal Rational Rose, esso permette infatti lo sviluppo con linguaggi visuali e non di diversi tipi. La scelta del linguaggio determina la complessità o meno del codice, considerando le diverse possibilità dei linguaggi disponibili. Per questo sviluppo, data l'entità del problema che richiede un'interfaccia utente semplice e immediata perché indirizzata ad un archivio di segreteria dove difficilmente gli utenti sono esperti in campo informatico, la scelta è stata giustamente orientata verso un linguaggio di tipo visuale come il Visual Basic. Molti linguaggi oggi in uso mettono a disposizione dei prodotti che permettono lo sviluppo facile e veloce di sistemi software attraverso strumenti simili al Rational Rose.

Setup

Saranno ora indicate le operazioni di setup necessarie per l'avvio della realizzazione del progetto:

Avviare Rastional Rose

Se si sta usando Rose Enterprise, si sconsiglia l'uso di un FrameWork (cliccare sul bottone cancel nel FrameWork Wizard).

Effettuare la scelta del linguaggio di default e orientarla verso Visual Basic

Dal menù Tools scegliere il comando Options, scegliere la voce Notation Tab, nel campo Default Language Field selezionare fra le scelte offerte quella desiderata (in questo caso Visual Basic)

Scegliere il centro di controllo

Ancora dalla voce Options del menù scegliere Diagram Tab e selezionare Focus of Control checkbox

Visualizzare tutti gli attributi e le operazioni

Dalla voce Options del menù scegliere Diagram Tab e selezionare Show all Attributes e Show all Operations checkboxes.

Inizio operazioni

Verranno ora mostrate e descritte tutte le operazioni effettuate durante lo viluppo del prodotto, ogni operazione sarà supportata dall'immagine della form che la interessa e dai comandi necessari per effettuarla.

Cominceremo lo sviluppo del Problema di Registrazione di Corsi creando un Use Case Diagram. Questo tipo di diagramma è costituito da actors, use cases e dalle relazioni fra questi.

Aprire il Main Use Case Diagram

Cliccare il + vicino alla cartella Use Case View nel Browser.

Fare un doppio click nel diagramma Main per aprire il diagramma.

Il primo passo è quello di identificare gli actors coinvolti nello sviluppo. Un actor  è definito come qualcuno o qualcosa che interagisce con il sistema durante lo sviluppo. Per il nostro problema sono stati identificati quattro attori:

Student (studente), Professor (professore), un Registrar (segretario incaricato delle registrazioni), e Billing System (sistema di archiviazione).

Selezionare l'icona degli attori dalla barra degli strumenti del programma (l'icona contrassegnata dal disegno di un omino stilizzato).

Cliccare nel diagramma per posizionare l'actor.

Mentre l'actor è ancora evidenziato digitare il nome da attribuirgli (es. Student).

Ripetere l'operazione per tutti gli altri attori coinvolti nel progetto (Professor, Registrar, Billing System).

Ora saranno identificati gli use cases per ogni actor considerato. Un use case è una funzione che viene fornita dal sistema. Essi possono essere facilmente individuati considerando ciascun actor e il modo in cui interagisce con il sistema. In questo modello lo studente necessita della registrazione dei corsi. L'archivio riceve le informazioni di registrazione. Il professore necessita di una lista dei corsi. Il segretario necessita della possibilità di organizzare un programma di studi.

Selezionare l'icona use case dalla barra degli strumenti (l'icona contrassegnata da un ovale).

Cliccare nel diagramma per posizionare l'use case.

Mentre l'use case è ancora selezionato digitare il nome da attribuirgli (es. Registration for Courses).

Ripetere l'operazione per gli altri use case coinvolti (Request Course Roster, Manage Curriculum).

La comunicazione fra use cases e actors viene effettuata attraverso delle relazioni. Una freccia unidirezionale viene usata per evidenziare la direzione della comunicazione (chi comincia la comunicazione). Nel sistema di registrazione dei corsi lo Student inizia la comunicazione con lo use case Registration for Courses. Il Registrar inizia la comunicazione con lo use case della Manage Curriculum.

Selezionare dalla barra degli strumenti la freccia unidirezionale delle relazioni (l'icona contrassegnata da una freccia).

Cliccare sull'actor Student e indirizzare la linea verso lo use case della Registration for Courses.

Allo stesso modo relazionare Registration for Courses con il Billing System (con direzione da Registrazione dei Corsi a Archivio)

Ripetere le operazioni per tutte le altre relazioni che interessano il diagramma.

Nota: Se mentre si selezione la freccia dalla barra degli strumenti si tiene premuto anche Shift Key, non sarà necessario poi riselezionare la freccia per riutilizzarla.

Le funzionalità e le relazioni fra use case e actors possono anche essere visualizzate in un diagramma sequenziale. Questo diagramma è uno degli strumenti che permettono di visualizzare, nel corso degli eventi, cosa succede ad uno use case. Viene qui considerato l'esempio dell'inserimento di uno studente nella programmazione di un corso.

Cliccare con il tasto destro nello use case Registration for Courses nel browser creando un piccolo sotto menù.

Selezionare dalla voce New il comando del menù Sequence Diagram . Questo comando permetterà di aggiungere diagramma di sequenze chiamato New Diagram nel browser.

Mentre il New Diagram è ancora selezionato, digitare il nome del diagramma (in questo caso Add a Course).

Saranno aggiunti ora al diagramma le operazioni logiche e gli oggetti necessari per le funzionalità del sistema. Dopo aver aperto il diagramma con un doppio click nel diagramma nel browser. Se questo scenario deve essere inizializzato dall'actor Student possiamo ora disegnare lo Student nel diagramma. L'actor disegnato necessita un nome per fornire chiarezza al disegno. Il nome può essere scelto in modo arbitrario, nell'esempio proposto la scelta è caduta su "Joe".

Aprire il diagramma con un doppio click nell'icona del diagramma nel browser.

Cliccare l'actor Student nel browser e disegnarlo nel diagramma aperto.

Cliccare lo Student nel diagramma e digitare il nome assegnatogli.

In questo scenario lo studente deve riempire informazioni in una Registration Form (form di registrazione) che deve poi essere presentata. Questo implica l'esistenza di un oggetto Registration Form, incaricata di ricevere le informazioni dallo Student.

Sarà ora creata la form e aggiunti due messaggi, "fill in info" (riempimento della form con le informazioni dello studente) e "submit" (presentazione della form).

Selezionare l'icona oggetto dalla barra degli strumenti (l'icona contrassegnata da un rettangolo).

Cliccare nel Sequence Diagram (diagramma di sequenze) per posizionare l'oggetto.

Mentre l'oggetto è ancora selezionato digitare il nome (in questo caso Registration Form).

Cliccare per selezionare l'oggetto messaggio dalla barra degli strumenti (l'icona contrassegnata dalla freccia).

Cliccare sulla linea tratteggiata di Student e disegnare la freccia fino alla linea tratteggiata della Registration Form.

Mentre la freccia è ancora selezionata digitare il messaggio (es. fill in information).

Ripetere le ultime tre operazioni per creare il messaggio submit.

A questo punto la Registration Form manda un messaggio al Manager. Il messaggio consiste nell'avvertimento che uno studente deve essere aggiunto alla programmazione dei corsi. Lo studente Joe ha scelto il corso della materia 101.

Selezionare l'icona oggetto dalla barra degli strumenti (l'icona contrassegnata da un rettangolo).

Cliccare nel diagramma di sequenze per posizionare l'oggetto.

Mentre l'oggetto è ancora selezionato digitare il nome (in questo caso Manager).

Cliccare per selezionare l'oggetto messaggio dalla barra degli strumenti (l'icona contrassegnata dalla freccia).

Cliccare sulla linea tratteggiata della Registration Form e disegnare la freccia fino alla linea tratteggiata del Manager.

Mentre la freccia è ancora selezionata digitare il messaggio (in questo caso add Joe to Math 101).

Il manager comunica ora al corso Math 101 che lo studente Joe vuole essere aggiunto nel corso.

Selezionare l'icona oggetto dalla barra degli strumenti (l'icona contrassegnata da un rettangolo).

Cliccare nel diagramma di sequenze per posizionare l'oggetto.

Mentre l'oggetto è ancora selezionato digitare il nome (in questo caso Math 101).

Cliccare per selezionare l'oggetto messaggio dalla barra degli strumenti (l'icona contrassegnata dalla freccia).

Cliccare sulla linea tratteggiata del Manager e disegnare la freccia fino alla linea tratteggiata della Math 101.

Mentre la freccia è ancora selezionata digitare il messaggio (in questo caso add Joe).

Il corso in questione (Math 101) chiede all'ente che gestisce l'offerta dei corsi (che qui verrà chiamato Section1), se il corso è attivato o meno (nella rappresentazione grafica la risposta sarà affermativa) e le comunica l'aggiunta dello studente Joe.

Selezionare l'icona oggetto dalla barra degli strumenti (l'icona contrassegnata da un rettangolo).

Cliccare nel diagramma di sequenze per posizionare l'oggetto.

Mentre l'oggetto è ancora selezionato digitare il nome (in questo caso Section1).

Cliccare per selezionare l'oggetto messaggio dalla barra degli strumenti (l'icona contrassegnata dalla freccia).

Cliccare sulla linea tratteggiata della Math 101 e disegnare la freccia fino alla linea tratteggiata della Section1.

Mentre la freccia è ancora selezionata digitare il messaggio (in questo caso accepting students?) con il quale viene verificata la disponibilità dell'iscrizione.

Ripetere le operazioni 4, 5, 6, per l'iscrizione di Joe (il messaggio sarà quindi add Joe).

Ora l'Archivio deve registrare che Joe è iscritto al corso di Math 101.

Selezionare l'icona oggetto dalla barra degli strumenti (l'icona contrassegnata da un rettangolo).

Cliccare nel diagramma di sequenze per posizionare l'oggetto.

Mentre l'oggetto è ancora selezionato digitare il nome (in questo caso Bill).

Cliccare per selezionare l'oggetto messaggio dalla barra degli strumenti (l'icona contrassegnata dalla freccia).

Cliccare sulla linea tratteggiata del Section1 e disegnare la freccia fino alla linea tratteggiata dell'archivio Bill.

Mentre la freccia è ancora selezionata digitare il messaggio (in questo caso Send bill for Math 101 to Joe).

Come si è visto gli oggetti nel Sequence Diagram sono raggruppati in classi, ogni passo viene eseguito spedendo dei messaggi da una classe ad un'altra. Una classe è un modello che permette la creazione di oggetti. Basandosi sul nostro diagramma di sequenze possiamo identificare le seguenti classi:

Registration Form è un oggetto della classe RegForm

Manager è un oggetto della classe Manager

Math101 è un oggetto della classe Course

Section1 è un oggetto della classe CourseOffering

Bill è un'interfaccia per i sistemi di archiviazione esterni, il nome che sarà usato per la sua classe sarà BillingSystem

Le classi verranno create nella Logic View di Rational Rose.

Cliccare sulla cartella Logical View nel browser per visualizzare il sottomenu di Logical View.

Selezionare dal menu il comando Class Menu Command dalla voce New. Questo permetterà di aggiungere una nuova classe nel browser.

Mentre la classe è ancora selezionata digitare il nome (es. RegForm).

Ripetere il passo 3 per tutte le altre classi (Manager, Course, CourseOffering, BillingSystem).

Dopo aver creato le classi esse devono essere documentate. La documentazione sarà aggiunta attraverso la finestra di documentazione (Documentation Window).

Selezionare la classe CourseOffering nel browser.

Digitare la sua documentazione nella Documentation Window.

Il processo di disegno di diagrammi e di creazione di classi finché non si ha la sicurezza che nessuna classe sarà più aggiunta in seguito, una tale esigenza comporterebbe dei problemi per l'aggiunta di una nuova classe. Solitamente quando si continua a trovare classi e messaggi che possono essere racchiuse in altri già creati è consigliato l'abbandono di questo passo della realizzazione.

La vista delle classi nel browser è buona ma il metodo necessita anche di una rappresentazione grafica. Per realizzare questo lo strumento Rational Rose fornisce un diagramma per le classi (Main Class Diagram).

Con un doppio click sul diagramma Main nel browser aprire il diagramma.

Selezionare dalla voce del menu Query il comando Add Classes.

Selezionare il bottone All>> per aggiungere tutte le classi.

Cliccare il bottone Ok per chiudere la finestra e aggiungere le classi nel diagramma.

Riarrangiare le posizioni delle classi nel diagramma come si ritiene necessario

Nota: le classi possono anche essere aggiunte nel diagramma direttamente dal browser, selezionandole e trasportandole all'interno del diagramma. Questa operazione può essere effettuate solamente per un diagramma alla volta.

L'UML ha un concetto di tipo che può essere usato per creare nuovi tipi di elementi per la modelllazione. Questo fornisce la possibilità di aggiungere significato a un modello. Saranno usati dei tipi di interfaccia predefiniti per la classe BillingSystem, che costituisce la classe di interfaccia con il sistema di archiviazione esterno.

Con un doppio click sulla classe BillingSystem nel diagramma Main si renderà la specificazione visibile.

Cliccando sulla freccia nel campo del tipo si renderà visibile il sottomenù.

Selezionare il tipo Interface.

Cliccare sul bottone Ok per chiudere la specificazione.

Ripetere il processo per la classe RegForm usando il tipo Form.

Relazioni fra classi sono aggiunte per facilitare la comunicazione fra oggetti. Diagrammi sequenziali vengono analizzati per capire cosa devono comunicarsi degli oggetti. Se gli oggetti devono essere in comunicazione si verifica la necessità di una via di comunicazione fra le loro classi. Due tipi comuni di relazione sono le associazioni e le aggregazioni.

Una associazione è una connessione bidirezionale fra classi. Esaminando il diagramma della sequenza "Add a Course" possono essere individuate le seguenti associazioni: RegForm con Manager, Manager con Course, Manager con Bill.

Selezionare l'icona associazioni dalla barra degli strumenti (contrassegnata da una linea).

Cliccare sulla classe RegForm e tracciare la linea di associazione alla classe Manager.

Ripetere le operazioni precedenti per le altre associazioni elencate sopra.

Una aggregazione è una forma di relazione più forte dell'associazione. Essa evidenzia la relazione fra un insieme e le sue parti costituenti. In questo esempio sarà creata una aggregazione fra le classi Course e CourseOffering (la classe Course è compresa nella classe CourseOffering).

Selezionare l'icona aggregazione dalla barra degli strumenti (contrassegnata da una linea con un diamante).

Cliccare sulla classe che rappresenta la parte costituente Course Offering.

Tracciare la linea di aggregazione sulla classe che costituisce l'insieme Course .

Gli indicatori di molteplicità sono aggiunti alle aggregazioni nel modello per evidenziare "quanti" oggetti compongono la relazione.

Selezionare l'icona aggregazione dalla barra

degli strumenti (contrassegnata da una linea con un diamante).

Selezionare la molteplicità attraverso il comando del menù One or More.

Cliccare con un tasto destro sulla linea di aggregazione vicino alla classe Course.

Specificare la molteplicità attraverso il comando del menù 1.

La struttura di una classe è rappresentata dall'insieme dei suoi attributi. La struttura viene identificata esaminando le richieste del problema (l'esame spetta solitamente ad un analista di problemi informatici). Nel modello dell'esempio ad ogni corso offerto (istanza della classe CourseOffering) viene associata una specifica locazione, questa è un attributo.

Cliccare con il tasto destro sulla classe CourseOffering sul diagramma delle classi.

Selezionare dal menù New la voce Attribute. Questo aggiungerà un attributo alla classe di cui dovrà essere definito il tipo e il nome.

Mentre l'attributo è ancora selezionato digitare il nome.

Il comportamento di una classe è rappresentato dal suo set di operazioni. Le operazioni sono identificate inizialmente nel diagramma delle sequenze.

Il primo passo è quello di assegnare gli oggetti alle classi nel diagramma delle sequenze.

Aprire diagramma di  sequenza di Add a Course con un doppio click nel diagramma nel browser.

Selezionare con un click la classe CourseOffering nel browser.

Tracciare la classe CourseOffering nell'oggetto Section1.

Quando un oggetto è stato rappresentato in una classe, possono essere tracciati i messaggi che riceve per eseguire operazioni (nuove o già definite nella classe).

Cliccare con il tasto destro sul messaggio "accepting students?" per rendere visibile il sottomenu.

Selezionare la voce <new operation> del menu per rendere visibile la Oparation Specification.

Digitare il nome della nuova operazione: offeringOpen.

Cliccare sul bottone Ok per chiudere la Operation Specification.

Quando una nuova operazione è stata creata, i messaggi possono essere tracciati sulle operazioni.

Cliccare con il tasto destro sul messaggio "accepting students?" per rendere visibile il sottomenu.

Selezionare l'operazione offeringOpen().

Alla fine si raggiungerà un punto dove si verificherà la possibilità di generare regole per le classi del modello. Qui sarà usato il Component View del software per specificare i componenti. Rose automaticamente creerà un diagramma dei componenti chiamato Main.

Cliccare sul + vicino al pacchetto Component View nel Browser per espanderlo.

Con un doppio click sul diagramma Main per aprire il diagramma dei componenti principali.

In questo modello saranno creati due componenti: Registration e BillingSystem.

Cliccare per selezionare l'icona componente dalla barra degli strumenti.

Cliccare sul diagramma per posizionare il componente.

Mentre il nuovo componente è ancora selezionato, digitare il suo nome (in questo caso Registration). Probabilmente sarà necessario ridimensionare il componente.

Ripetere i punti precedenti per creare il componente BillingSystem.

A ciascun componente verrà assegnato un linguaggio. Questo implica che tutte le classi assegnate al componente saranno sviluppate con il linguaggio scelto. In questo esempio il componente BillingSystem sarà implementato con Java e il componente Registration con Visual Basic.

Con un doppio click sul diagramma dei componenti del componente BillingSystem nel browser visualizzare la Component Specification.

Cliccare sulla freccia accanto all'etichetta Language per visualizzare la lista dei linguaggi disponibili.

Selezionare il linguaggio desiderato.

Cliccare sul bottone Ok per chiudere la Specification.

Con un doppio click sul componente Registration è possibile vedere che il linguaggio selezionato è Visual Basic. Rose ha settato il linguaggio automaticamente perché Visual Basic era stato selezionato inizialmente come linguaggio di default.

Quando un componente è stato creato, le classi nel modello devono essere assegnate al componente.

Con un doppio click sul componente BillingSystem nel diagramma o nel browser per visualizzare la Specification.

Selezionare la tabella Realizes.

Cliccare con il tasto destro sulla classe Billingsystem per rendere visibile il sottomenu.

Selezionare il comando Assign.

Assegnare tutte le altre classi al componente Registration.

Essendo la classe BillingSystem una classe di interfaccia essa è disegnata usando la notazione lollypop (denaro).

Le relazioni fra i componenti sono visualizzate usando una relazione di dipendenza. In questo il componente Registration comunica al componente BillingSystem attraverso l'interfaccia del BillingSystem.

Selezionare l'icona Dependency Relationship dalla barra degli strumenti.

Cliccare sul componente Registration e tracciare la freccia al componente BillingSystem.

Salvare il modello

Sarà ora generato il codice per il componente Registration. Essendo il componente impostato per un'implementazione attraverso Visual Basic sarà usato il dispositivo di Visual Basic Generate Code, selezionato dal menu.

Selezionare il componente Registration dal diagramma dei componenti.

Selezionare l'accessorio, Generate Code dal menu.

Questo visualizzerà il wizard per generare il codice di Visual Basic. In questo esempio, saranno accettati tutti i default della generazione del codice, pertanto è necessario solamente cliccare sul bottone Finish.

Cliccare sul bottone Finish per accettare tutte le scelte visualizzate.

Il generatore di codice produrrà un progetto VB standard chiamato Registration. In VB, un progetto standard è creato con una form chiamata Form1. Il wizard del Rose riconosce che questa form è contenuta nel codice del VB ma non nel modello e pone perciò la domanda se la si vuole inserire nel modello. Qui sarà chiesto di eliminarla.

Selezionare la classe Form1.

Cliccare il bottone Delete.

Cliccare sul bottone Ok per continuare il processo di generazione del codice.

Quando la generazione del codice è completata sarà visualizzata la finestra Summary.

Cliccare sul bottone close per terminare il processo di generazione del codice.

Sarà visualizzato ora il codice generato da Rose.

Selezionare il componente Registration nel diagramma componenti.

Selezionare il dispositivo Browse Visual Basic Source dal menu Visual Basic.

Si noti che Rose ha generato codice per tutte le classi assegnate al componente Registration.

Rose ha anche generato una form per la classe RegForm. Questo è dovuto al fatto che il processo di generazione del codice VB identifica che le classi con uno stereotipo di form sono particolari tipi di classi Visual Basic.

Si noti che la documentazione che era aggiunta al modello è ora aggiunta al codice.

Se si verificasse la malaugurata situazione che il progettista scopre, dopo aver fatto disegni, analisi, dopo aver generato il codice di un intero progetto, che necessita di una nuova operazione, Rose fornisce la possibilità di andare a modificare il codice in VB.

Selezionare la voce Add Procedure dal menu.

Digitare il nome della nuova procedura (es. incrementCount).

Selezionare la il bottone Function.

Cliccare il bottone Ok per chiudere la finestra Add Procedure.

Dopo aver modificato il codice esso si trova in disaccordo con il modello generato dalla Rose. Viene qui utilizzata una tecnica al rovescio, chiamata Reverse Engineering.

Selezionare il wizard Reverse Engineering dalla voce Rose98 del menu Add-Ins.

Selezionare il modello da modificare.

Cliccare sul bottone Ok per avviare il wizard.

Essendo qui stata modificata solamente la classe CourseOffering essa dovrà essere l'unica da aggiornare.

Cliccare sulla checkbox vicino a Forms per escludere il pacchetto Forms.

Cliccare sulla checkbox vicino a Modules per escludere il pacchetto Modules.

Cliccare il + vicino alla cartella Class Modules per renderne visibile il contenuto.

Cliccare sulla checkbox vicino alla classe Course e alla classe Modules per escludere le classi.

Come prima saranno mantenute le impostazioni di default e poi selezionato il bottone Finish per completare il processo.

La finestra di sommario viene visualizzata alla fine del processo Reverse Engineering.

Cliccare il bottone close per completare il processo Reverse Engineering.

Verrà ora visualizzato il diagramma delle classi per vedere come il modello è stato modificato.

Se la cartella Logical View non è espansa, cliccare sul + per espanderla.

Aprire il diagramma delle classi Main nel Browser con un doppio click.

Riarrangiare le classi come desiderato selezionandole e tracciandole nelle nuove locazioni.

Si noteranno gli attributi e operazioni aggiunte dal processo di generazione del codice.

Si noti anche che l'operazione incrementCount() per la classe CourseOffering è stata aggiunta al modello.

In questo piccolo demo, si è visto come Rational Rose può essere usato nelle fasi di analisi, disegno, implementazione del codice, visualizzazione , produzione della documentazione dello sviluppo di un sistema software.

La velocità di esecuzione dello sviluppo del progetto è stata, attraverso l'adozione di queste tecniche, enormemente diminuita, aumentando inoltre la chiarezza della struttura del prodotto, che è ovviamente attinente allo standard UML.

CONCLUSIONI

Lo sviluppo del progetto ha permesso la specificazione e l'acquisizione dello standard per la progettazione UML. Gli obbiettivi principali che erano stati proposti sono stati raggiunti in modo soddisfacente. Le nozioni teoriche e specifiche del manuale sono state quasi ignorate nello sviluppo della tesi, vista l'impossibilità di una analisi specifica nel tempo concesso. Il lavoro è stato principalmente concentrato sull'acquisizione di informazioni relative alle motivazioni per le quali è stato ideato l'UML e a quali sono le sue funzioni. Oltre ai contenuti dello standard è stato possibile affrontare altri temi di utile riscontro anche in un eventuale esperienza lavorativa, come l'utilizzo di software di traduzione, per quanto problematico sia stato lo sviluppo di questo punto (vedi appendice Traduzione del Manuale UML, e l'utilizzo di uno dei prodotti per lo sviluppo di software che rispondono alle metodologie dettate dallo standard UML. Il prodotto utilizzato è stato il Rational Rose 98, con il quale si è proceduti allo sviluppo dell'esempio documentato nel punto .4. Considerando la vastità dell'argomento e la continua evoluzione a cui esso è sottoposto questo documento potrebbe ampliato secondo le specifiche esigenze. Il materiale necessario per un'implementazione di questo progetto può facilmente essere reperibile nei siti citati nella bibliografia (punto .7), seguendo articoli trovati su giornali specializzati oppure semplicemente contattando le sedi delle industrie software che distribuiscono i prodotti basati sullo standard UML.

APPENDICI

TRADUZIONE DEL MANUALE UML

Come già accennato nella descrizione del progetto, inizialmente era stata proposta la traduzione completa del manuale. La traduzione sarebbe stata effettuata attraverso l'utilizzo di alcuni programmi software forniti dall'istituto. Dopo aver valutato il risultato della traduzione fornita dai traduttori, vista l'evidente necessità di una accurata revisione del testo, è stata presa la decisione di proporre la traduzione solamente di una parte del manuale. La scelta è caduta sul sommario del manuale, che può fornire al lettore una panoramica generale delle metodologie UML indirizzando eventualmente ricerche specifiche.

Prove di traduzione

Secondo il disegno iniziale del progetto le prove di traduzione, necessarie per valutare la qualità dei prodotti software di traduzione e per sperimentare il metodo da utilizzare per l'utilizzo di tali prodotti (es. valutando i diversi risultati ottenuti variando le opzioni dei programmi), erano state suddivise nei seguenti punti:

Prova di traduzione di semplici frasi in lingua inglese

Prova di traduzione delle principali regole grammaticali inglesi

Prova di traduzione di alcuni pecifici vocaboli della microlingua inglese

Prova di traduzione di un periodo articolato di lingua inglese.

Il deludente risultato ottenuto già nel primo punto della scaletta ha indotto a scegliere uno sviluppo diverso del progetto, considerando anche i tempi relativamente ristretti concessi per la realizzazione.

Analisi della traduzione

Per entrambi i software di traduzione è stato necessario convertire i files del manuale da tradurre, in formato .PDF, in un testo con formato.TXT. Convertito il testo è stato possibile iniziare la fase di traduzione semplicemente selezionando il comando adatto dal software considerato (vista la scarsa esperienza con questo tipo di prodotti e la scarsa qualità del risultato sono state mantenute le opzioni di default).

Il programma ItalWin ha necessitato per la traduzione la creazione di un progetto di tipo .WRI (specifico del programma). L'altro software considerato, il Trascend  ha fornito un risultato in formato .TXT (testo normale).

Il testo trsadotto ha necessitato poi un'attenta fase di revisione (effettuata anche con l'aiuto del docente di inglese), per portare la traduzionme ad un livello decente di comprensione.

Scelta del software e considerazioni

Vista la scarsa qualità del risultato fornito dai traduttori nei testi tradotti non sono stati confrontate e valutate a fondo le differenze nella traduzione, non sufficenti per indirizzare la scelta verso uno dei due prodotti. La scelta del software da usare è stata quindi principalmente influenzata dal fatto che l'ItalWin,  a conrario di Trascend, ha permesso di mantenere la formattazione originale del testo (anche se con misura e tipo di carattere diverso). Il software trascend forniva invece un risultato allineato inteamente su una riga continua e non riportando le parti evidenziate con diversi caratteri o diverse misure.

Per la fase di revisione è stato necessario impiegare un lungo periodo di tempo (complessivamente stimato attorno alle 8 ore) contrariamente alle aspettative. La difficoltà di questa è stata soprattutto influenzata dal linguaggio del manuale che, ovviamente, comportava l'impiego di molti termini tecnici e di una complessa struttura sintattica.

Esempio di traduzione con il software scelto

Questo parte dell'appendice riporta la traduzione di una piccola parte di un testo, tratto dal sommario del manuale, come è stata fornita dal software ItalWin (scelto per la traduzione), allo scopo di fornire un'idea della qualità del risultato ottenuto non è stata quindi praticata alcuna revisione sul testo prodotto. Per un adeguato confronto sono state fornite anche la versione revisionata e quella originaria, in lingua inglese, tratta dal manuale.

ItalWin

PREFAZIONE

Il ha Unificato Lingua della Modellistica (UML) è una lingua per specificare, visualizza, costruisce, e documenta i manufatti di sistemi del software, come allora come per modellistica dell'affare ed altro sistemi del non-software. L'UML rappresenta una raccolta di migliori pratiche dell'ingegneria che hanno verifica riuscito nella modellistica di sistemi grandi e complessi.

L'UML definizione consiste dei documenti seguenti:

UML Semantiche- definisce le semantiche ricche e sintassi espressiva del ha Unificato Lingua della modellistica. L'UML è [architecturally] del [layered] e ha organizzato da pacco. Fra ciascuno pacco gli elementi del modello sono definiti in termini della loro sintassi astratta (usa l'UML classifica notazione del diagramma), bene-modulo-edness regole (usa testo ed Oggetto Espressioni della Lingua della costrizione), e semantiche usa testo preciso).

Due [appendices] è incluso: UML Glossario ed Elementi Standard.

UML Notazione Guida- definisce nozione e provvede sostiene esempi. L'UML notazione rappresenta la sintassi grafica per esprimere le semantiche ha descrivuto da il UML [metamodel].

UML Dilazione per l'Objectory Cita per Software Engineeering ed UML Dilazione per Modellistica dell'Affare- Questi UML dilazioni includono [process-] e dilazioni dominio-specifiche all'UML, in termini dei suoi meccanismi della dilazione e icone del diagramma processo-specifiche.

L'UML usa OCL, ha definito separatamente nella Specificazione della Lingua della Costrizione dell'Oggetto

documento.

Testo Originale

PREFACE

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

The UML definition consists of the following documents:

UML Semantics - defines the rich semantics and expressive syntax of the Unified Modeling Language. The UML is layered architecturally and organized by package. Within each package, the model elements are defined in terms of their abstract syntax (using the UML class diagram notation), well-formedness rules (using text and Object Constraint Language expressions), and semantics (using precise text). Two appendices are included: UML Glossary and Standard Elements.

UML Notation Guide - defines notion and provides supporting examples. The UML notation represents the graphic syntax for expressing the semantics described by the UML metamodel.

UML Extension for the Objectory Process for Software Engineeering and UML Extension for Business Modeling - These UML extensions includes process- and domain-specific extensions to the UML, in terms of its extension mechanisms and process-specific diagram icons.

The UML uses OCL, defined separately in the Object Constraint Language Specification

document.

Testo Revisionato

PREFAZIONE

L' »Unified Modelling Language» (UML) è un linguaggio usato per specificare, visualizzare, costruire e documentare i manufatti di sistemi software, come la modellistica nel campo degli affari ed altri sistemi non-software.

L'UML rappresenta una raccolta delle migliori pratiche dell'ingegneria che sono state verificate con successo nella modellistica di grandi e complessi sistemi.

La definizione dell'UML consiste nei seguenti documenti:

Semantiche dell'UML. Definisce le ricche semantiche e la sintassi espressiva dell'«Unified Modelling Language». L'UML è strutturato e organizzato in pacchetti. Attraverso ciascun pacchetto gli elementi del modello sono definiti in sessioni basate sulla loro sintassi astratta (usando la notazione a diagrammi di classe UML), modulazione delle regole (usando testi e costrizioni delle espressioni del linguaggio), e semantiche (usando un testo preciso). Due appendici sono incluse: Glossario UML ed Elementi Standard.

Notazione Guida dell'UML Definisce nozioni e provvede alla presentazione degli esempi. La notazione UML rappresenta la sintassi grafica per esprimere le semantiche descritte dal metamodello UML.

Estensioni dell'UML per la Progettazione ad Oggetti nell'Ingegneria del Software ed estensione UML per Modellazione nel campo Commerciale. Questa sezione include processi e estensioni di domini specifici all'UML, in sessioni dei suoi meccanismi estesi e icone del diagramma processo-specifiche.

L'UML usa OCL, definito separatamente nel documento Object Constraint Language Specification (Specificazione dell'OCL).

STORIA E CRONACA DELL'UML

Il processo di standardizzazione e unificazione metodologica che ha portato ad UML ha avuto origine nel 1994 con l'ingresso di Jim Rumbaugh nella società Rational, in cui operava Grady Booch, ed è proseguito con l'arrivo nella stessa società, a fine 1995, di Ivar Jacobson.

La prima versione è stata proposta nell'ottobre 1995 da Booch e Rumbaugh: Unified Method versione 0.8.

Nell'ottobre '96, con il contributo di Jacobson, fu proposto l'Unified Modelling Languae, versione 0.9.

Un'ulteriore versione sarà proposta dagli studiosi nel giugno dello stesso anno, la 0.91.

Nel gennaio '97 esce UML 1.0, proposto da Booch, Rambaugh, Jacobson, in collaborazione con alcuni partner UML, tra cui Microsoft, Oracle, Hewlett-Packard, digital, Texas Instruments), in risposta alla richiesta avanzata dall'OMG (Object Management Group) per un framework di interoperabilità tra strumenti di analisi e disegno. All'OMG rrivano anche altre proposte, fra cui quelle di IBM e Platinum.

Nel settembre '97, dopo accordi con Platinum, IBM e altre società la versione 1.1 dell'Unified Modelling Language viene sottoposta all'approvazione di OMG. E' una proposta congiunta di Rational Software, Microsoft, Hewlett-Packard, Oracle, Sterling Software, MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, I-Logix, IBM, ObjecTime, Platinukm Technology, Ptech, Taskon, Reich Tecnologies, Softeam, e alcuni altri minori.

I cambiamenti più rilevanti rispetto alla versione 1.0 sono:

Maggiore formalismo

Miglioramento dei meccanismi di packaging

Unificazione dei concetti di collaborazione ed interazione

Semplificazione della parte di modello relativa a classi, tipi, interfacce

unificazione dei concetti relativi alle associazioni

Estensione dei concetti inerenti la gestione dei modelli, tra cui modelli e sottoinsiemi

estensione dei modelli relativi ai casi d'uso

miglioramento del mapping tra la notazione ed i concetti semantici

Il giorno 17 novembre 1997 UML 1.1 diventa ufficialmente uno standard OMG con il nome ufficiale di «UML OMG 1.0

CONVERSIONE DI NOMI E DIGITAZIONE

OCL viene usato per la formulazione di regole di forma. Alcune seguenti convenzioni sono usate per migliorare la leggibilità dei documenti, esse riguardano però un puro aspetto di presentazione del contenuto.

Uso del linguaggio descrittivo

Si è cercato all'interno del linguaggio di fare un uso preciso delle parti descrittive, attinendosi ai comuni significati della lingua usata. In alcuni casi è stato però utile usare alcune eccezioni:

Quando ci si riferisce ad una istanza di qualche metaclasse, spesso viene omessa la parola «istanza». Ad esempio per indicare una «istanza di una classe», spesso viene solamente usata la parola «classe». Così anche per le «istanze di associazioni» ecc.

Ogni volta che una parola coincide con il nome di qualche costruzione in UML, c'è un riferimento a questa costruzione.

termini che necessitano i prefissi »sub», »super», »meta», sono scritti come una sola parola (es. metamodel, metaclass, etc.).

Traduzioni

Nella descrizione dell'UML sono state adottate le seguenti convenzioni:

Quando c'è un riferimento ad una costruzione UML, non la sua rappresentazione nel metamodello, è usata una parte descrittiva.

La prima volta che un meccanismo o una costruzione in UML viene no9minata è evidenziata con il carattere italico.

I nomi delle metaclassi e delle metaassociazioni/assiciazioni iniziano sempre con la lettera maiuscola.

Attributi e operazioni nei metamodeli sono invece indicati con la scrittura minuscola.

Metaattributi di tipo booleano sono sempre preceduti dal suffisso 'is' (es. 'isAbstract').

I nomi di metaclassi astratte usati nel metamodello sono evidenziati in italico, ma no distinti dalle altre metaclassi nel testo.

Nomi di stereotipi sono delimitati dalle virgolette e iniziano con la lettera minuscola (es. «type»

STRUMENTI BASATI SULL'UML

RATIONAL ROSE 98 ENTERPRISE EDITION

In questa appendice verranno illustrate le diverse tipologie del prodotto Rational Rose 98 usato nel punto 4. per lo sviluppo dell'esempio presentato. La scelta è caduta su questo prodotto considerando le ampie possibilità che esso fornisce. Le informazioni sono state tratte dal sito ufficiale dell'azienda Rational: www.Rational.com.

Modellizzare con UML

Rational Rose 98 fornisce un eccellente supporto per lo Unified Modeling Language (UML). UML permette agli analisti, agli architetti del software e agli sviluppatori di specificare, visualizzare e documentare qualsiasi sistema object-oriented. Fornendo un "linguaggio" comune per descrivere sistemi complessi, UML permette a diversi attori con diverse prospettive e percezioni di comunicare su un terreno comune. I ricercatori chiave di Rational, fra i quali Grady Booch, Ivar Jacobson e Jim Rumbaugh guidano lo sviluppo dello standard UML. L'Object Management Group (OMG) ha accettato la proposta Rational dello UML e lo ha adottato come standard ufficiale di notazione per il software design.

CBD - Component-Based Development

Usato per lo sviluppo di complessi sitemi di business, lo sviluppo component-based è emerso come uno dei più efficaci processi di progettazione. Gli utilizzatori di Rose possono ora modellare i loro componenti e le loro interfacce ancora più efficacemente. I componenti necessari per un progetto possono essere facilmente reverse-engineered (tecnica che permette di modificare lo sviluppo del sistema anche dopo aver eseguito le varie fasi della progettazione) per esplorare le interfacce e le interrelazioni di altri componenti nel modello. Con Rose 98 questo processo è semplice: basta fare drag and drop di componenti da un file system dentro nel diagramma dei componenti . Questo abilita a fare reverse engineering di componenti, a riusarli, a visualizzarli, adattarli, oppure ad acquisirne e crearnedi nuovi per il vostro sistema, velocemente e con semplicità.

Sviluppo Multi-language

E' sempre piu' frequente trovare grandi progetti che adoperano una varietà di linguaggi diversi. Rose 98 Enterprise Edition ha il supporto multi-languag, che vi permette di costruire componenti in linguaggi misti. Anche se la vostra apllicazione ha componenti C++, alcuni in Java, altri in Visual Basic, Rose 98 mantiene i vostri modelli consistenti, indipendentemente dal linguaggio di implementazione. Rose supporta C++, Java, Smalltalk e Ada, come pure Visual Basic, PowerBuilder e Forté. Rose 98 genera anche Interface Definition Language (IDL) per applicazioni CORBA e Data Description Language (DDL) per applicazioni database.

Round-trip engineering

Rose 98 permette di muoversi agilmente dall'analisi alla progettazione all'implementazione e di nuovo indietro all'analisi, supportando così tutte le fasi del ciclo di vita di un progetto. Questo stile di sviluppo iterativo e controllato permette ai progetti di iniziare con un set di requisiti noto, e poi di evolvere mentre i parametri di progetto cambiano o nuovi requisiti si aggiungono. Rational Rose 98 supporta questo processo di gestione dinamica di un progetto con il forward engineering, il reverse engineering e funzionalità di aggiornamento del modello tali che vi permettono di alterare la vostra implementazione, valutarne i cambiamenti, e automaticamente riportarli nel progetto. Il supporto di Rose per il round-trip engineering assicura che il ciclo di sviluppo iterativo sia controllato e produttivo.

Completo supporto di gruppo

Rational Rose 98 supportasquadre di analisti, architetti e ingegneri permettendo loro di operare in spazi di lavoro privati che contengono viste individuali dell'intero modello. Ogni individuao può modificare privatamente le sue parti di modello fino a quando non è pronto per essre condiviso col resto del gruppo. I cambiamenti sono resi disponibili agli altri notificandoli in un sistema di configuration-management e version-control (CMVC). Gli altri sviluppatori possono allora visualizzare e includere questi cambiamenti nel momento più opportuno. Rose 98 si integra con i principali strumenti CMVC, inclusi Rational ClearCase e Microsoft SourceSafe ed è aperto ad altri sistemi CMVC. E' anche strettamente integrato con il Microsoft Repository e con Unisys UREP ed è aperto ad altri repository. Per il massimo supporto di gruppo, Rose vi permette di pubblicare e condividere nuovi modelli proposti da privati sulla intranet  (rete situata all'interno di un ente privato) dell'azienda che si è occupata dello sviluppo.

Incredibile semplicità d'uso

Rose 98 è lo strumento di visual modeling da scegliere per parecchi tipi di progetti software. Oltre ad adoperare Unified Modeling Language, Rose 98 supporta elementi GUI familiari come il drag and drop con OLE automation. Ciò vi permette di integrarvi con applicazioni come Microsoft Word e usare Rose come OLE automation server. La compatibilità di Rose con le piattaforme Windows è stata comprovata nei Microsoft Usability Labs.

Rational Rose 98 Modeler Edition

E' il più diffuso strumento di modellazione al mondo. Fornisce un totale supporto per Unified Modeling Language 1.1 per gruppi di sviluppatori software e analisti di sistemi. La versione Modeler include supporto per la modellazione di processi di business, di oggetti e di applicazioni basate su componenti. Permette inoltre la comparazione visuale e la fusione di modelli in diversi stadi del progetto per facilitare lo sviluppo parallelo. Per una versatilità ancora maggiore, la Rose Extensibility Interface estende Rose con aggiunta di terze parti o permette di sviluppare metodi personalizzati.

Rational Rose 98 Professional C++ Edition

Include tutte le caratteristiche della versione Modeler, ma include anche la generazione ed il reverse engineering di codice C++. Fornisce un ambiente controllato e interattivo per diversi team di sviluppatori C++ che lavorano su diversi progetti. Le funzionalità di round trip engineering vi permettono di passare dalla progettazione al codice sorgente e viceversa, supportando perfettamente il ciclo di vita del vostro processo di sviluppo software. Questa versione fornisce anche suporto specifico per Microsoft Visual C++, incluse le applicazioni basate su MFC (Microsoft Foundation Classes) e ATL (Abstract Template Library).

Rational Rose 98 Professional Java^T Edition

Include tutte le caratteristiche della versione Modeler, più la generazione ed il reverse engineering di codice Java. Fornisce un ambiente controllato e interattivo per diversi team di sviluppatori Java che lavorano su diversi progetti. Le funzionalità di round trip engineering vi permettono di passare dalla progettazione al codice sorgente o byte e viceversa, supportando perfettamente il ciclo di vita del vostro processo di sviluppo software. Fornisce anche supporto specifico per JDK 1.02 e JDK 1.1.

Rational Rose 98 Professional Visual Basic Edition

Include tutte le caratteristiche della versione Modeler, più la generazione ed il reverse engineering di codice Visual Basic. Fornisce un ambiente controllato e interattivo per diversi team di sviluppatori VB che lavorano su diversi progetti. Le funzionalità di round trip engineering vi permettono di passare dalla progettazione al codice sorgente e viceversa, supportando perfettamente il ciclo di vita del vostro processo di sviluppo software. Rose 98 Professional Visual Basic Edition fornisce un supporto specifico per progetti multipli, permettendo agli utenti di modellare applicazioni e generare codice in molteplici progetti Visual Basic distinti.

Rational Rose 98 Evaluation Edition

E' esattamente Rational Rose 98 Enterprise Edition con una chiave a tempo di 30 giorni, che offre a chi vuole valutare Rose un tempo sufficiente per adoperare il prodotto e capire le sue molte caratteristiche e i suoi vantaggi.

GLOSSARIO DELL'UML

Convenzioni tipografiche

Le voci del glossario iniziano normalmente con una lettera minuscola. Viene però utilizzata la maiuscola nei casi in cui l'uso comune della parola lo richiede. Gli acronimi sono resi con tutte maiuscole, tranne quando appaiono tradizionalmente in minuscole.

Quando, in un termine con più parole, una o più tra queste parole viene racchiusa in parentesi quadre, ciò significa che si tratta di parole che possono essere omesse nello specificare il termine. Ad esempio, caso d'uso [classe di] può essere utilizzato semplicemente come caso d'uso.

Il glossario utilizza le seguenti convenzioni:

Diverso da: <termine. Indica un termine che ha un significato opposto, o fortemente divergente rispetto al termine di cui si sta parlando.

Vedi: <termine. Indica un termine collegato che ha significato vicino al termine di cui sta parlando, ma che non ne è un sinonimo.

Sinonimo: <termine. Indica un termine che ha lo stesso significato del termine di cui si sta parlando.

Acronimo: <termine. Indica che il termine è un acronimo. Viene fornita al lettore la dicitura del termine per esteso, con eccezione dei casi in cui la dicitura estesa sia poco utilizzata.

Note

Ogni termine del glossario viene riportato in neretto, seguito tra parentesi dalla forma originale inglese in carattere normale.

Es. aggregazione (aggregation)

Nella maggior parte dei casi, i termini del glossario sono tradotti in italiano. Sono stati però mantenuti i termini originali inglesi nei casi in cui:

corrispondano a stereotipi predefiniti in UML, o a concetti specifici che qualificano elementi di particolari diagrammi (uses, extends, participates; import, export)

siano termini molto diffusi, per i quali nell'uso italiano non sia disponibile una traduzione soddisfacente (package, template, thread)

Le traduzioni proposte per la parte esplicativa dei termini sono seguite, tra parentesi quadre, dall'originale inglese, per consentire una valutazione della traduzione stessa in termini di conformità ed adeguatezza.

Es. aggregazione (aggregation)

Una particolare tipologia di associazione, che specifica una relazione intero-parte tra l'aggregato (intero) e una parte componente. Diverso da:Composizione. [A special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. Contrast: composition.]

A

accettazione (reception)

Dichiarazione che un classificatore è pronto a reagire alla ricezione di un segnale. [A declaration that a classifier is prepared to react to the receipt of a signal.]

aggregato [classe] (aggregate [class])

Classe che rappresenta l'"intero" in una relazione di aggregazione (intero-parte). Vedi: Aggregazione [A class that represents the "whole" in an aggregation (whole-part) relationship. See: aggregation.]

aggregazione (aggregation)

Una particolare tipologia di associazione, che specifica una relazione intero-parte tra l'aggregato (intero) e una parte componente. Diverso da: Composizione. [A special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. Contrast: composition.]

aggregazione composita (composite aggregation)

Sinonimo: Composizione. [Synonym: composition.]

ambito di denominazione (namespace)

Parte del modello in cui possono essere definiti ed utilizzati dei nomi. All'interno di un ambito di denominazione, ogni nome ha un significato univoco. Vedi: Nome. [A part of the model in which the names may be defined and used. Within a namespace, each name has a unique meaning. See: name.]

analisi (analysis)

La fase del processo di sviluppo software il cui scopo principale è definire un modello del problema da trattare. L'analisi si focalizza su cosa dev'essere fatto, il disegno su come questo qualcosa dev'essere implementato. Diverso da: Disegno. [The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses what to do, design focuses on how to do it. Contrast: design.]

architettura (architecture)

La struttura dell'organizzazione di un sistema. Un'architettura può essere scomposta in modo ricorsivo, in parti che inte4ragiscono tra loro tramite interfacce, in relazioni che connettono le parti, e in vincoli che specificano le regole per l'assemblaggio delle parti. [The organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts.]

argomento (argument)

Valore specifico assegnato ad un parametro. Sinonimo: Paramentri Attuali. Diverso da: Parametro. [A specific value corresponding to a parameter. Synonym: actual parameter. Contrast: parameter.]

aspetto comportamentale del modello (behavioral model aspect)

Aspetto del modello che evidenzia il comportamento delle istanze in un sistema, tra cui i loro metodi, le loro collaborazioni, la storia dei loro stati. [A model aspect that emphasizes the behavior of the instances in a system, including their methods, collaborations, and state histories]

aspetto del modello (model aspect)

Una dimensione della modellazione che mette in luce qualità particolari del metamodello. Ad esempio, l'aspetto strutturale del modello mette in luce le qualità strutturali del metamodello. [A dimension of modeling that emphasizes particular qualities of the metamodel. For example, the structural model aspect emphasizes the structural qualities of the metamodel.]

aspetto strutturale del modello (structural model aspect)

Aspetto del modello che mette in luce la struttura degli oggetti in un sistema, comprendendo tipi, classi, relazioni, attributi ed operazioni. [A model aspect that emphasizes the structure of the objects in a system, including their types, classes, relationships, attributes and operations.]

associazione (association)

Relazione semantica tra due o più classificatori, che comporta connessioni tra le rispettive istanze. [The semantic relationship between two or more classifiers that involves connections among their instances.]

associazione binaria (binary association)

Associazione tra due classi. Caso particolare di un'associazione n-aria. [An association between two classes. A special case of an n-ary association.]

associazione di comunicazione (communication association)

In un diagramma di distribuzione, è un'associazione tra nodi che implica una comunicazione. Vedi: Deployment diagram. [In a deployment diagram an association between nodes that implies a communication. See: deployment diagram.]

associazione n-aria (n-ary association)

Associazione tra tre o più classi. Ogni istanza dell'associazione è un'ennupla di valori derivati dalle rispettive classi. Diverso da:Associazione Binaria. [An association among three or more classes. Each instance of the association is an n-tuple of values from the respective classes. Contrast: binary association.]

astrazione (abstraction)

Le caratteristiche essenziali di un'entità, che la distinguono da tutti gli altri tipi di entità. Un'astrazione definisce un confine dal punto di vista dell'osservatore. [The essential characteristics of an entity that distinguish it from all other kind of entities. An abstraction defines a boundary relative to the perspective of the viewer.]

attivazione (activation)

L'esecuzione di un'azione. Diverso da: activation [OMA]. [The execution of an action. Contrast: activation [OMA].]

attore [classe di] (actor [class])

Insieme coerente di ruoli, che gli utilizzatori dei casi d'uso assumono nell'interazione con i casi d'uso. Un attore ha un ruolo in ogni caso d'uso al quale partecipa. [A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates.]

attributo (attribute)

Proprietà di un classificatore, identificata con un nome, che descrive un insieme di valori che le istanze del classificatore possono assumere. Sinonimo: attribute [OMA]. [A named slot within a classifier that describes a range of values that instances of the classifier may hold. Synonym: attribute [OMA].]

azione (action)

La specifica di un comando (statement) eseguibile, che costituisce un'astrazione di una procedura computazionale. Un'azione dà origine ad un cambiamento di stato del modello, e viene eseguita inviando un messaggio ad un oggetto o modificando il valore di un attributo. [The specification of an executable statement that forms an abstraction of a computational procedure. An action results in a change in the state of the model, and is realized by sending a message to an object or modifying a value of an attribute.]

azione asincrona (asynchronous action)

Richiesta in cui l'oggetto che la effettua non resta in stato di pausa, in attesa dei risultati. Sinonimo: asynchronous request [OMA]. Diverso da: Azione Sincrona. [A request where the sending object does not pause to wait for results. Synonym: asynchronous request [OMA]. Contrast: synchronous action.]

azione sincrona (synchronous action)

Richiesta in cui l'oggetto mittente resta in stato di pausa ad attendere i risultati del servizio. Sinonimo: synchronous request [OMA]. Diverso da: Azione Asincrona. [A request where the sending object pauses to wait for results. Synonym: synchronous request [OMA]. Contrast: asynchronous action.]

B

binding (binding)

La creazione di un elemento del modello a partire da una template, che avviene fornendo argomenti corrispondenti ai parametri della template. [The creation of a model element from a template by supplying arguments for the parameters of the template.]

booleano (boolean)

Enumerazione i cui valori sono vero e falso. [An enumeration whose values are true and false.]

C

cardinalità (cardinality)

Il numero di elementi in un insieme. Diverso da: Molteplicità. [The number of elements in a set. Contrast: multiplicity.]

caso d'uso [classe] (use case [class])

Specifica di una sequenza di azioni, varianti incluse, che un sistema (o un'altra entità) può compiere, interagendo con gli attori del sistema. Vedi: Istanze use case. [The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. See: use case instances.]

classe (class)

Descrizione di un insieme di oggetti che condividono i medesimi attributi, operazioni, metodi, relazioni, e hanno lo stesso significato. Una classe può utilizzare un insieme di interfacce per specificare i diversi raggruppamenti di operazioni che mette a disposizione del proprio ambiente. Sinonimo: class [OMA]. Vedi: interfaccia. [A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. Synonym: class [OMA]. See: interface.]

classe associativa (association class)

Elemento di modellazione che ha caratteristiche sia dell'associazione che della classe. Una classe associativa può essere vista come un'associazione che ha anche le caratteristiche di classe, o come una classe che ha anche caratteristiche di associazione. [A modeling element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties.]

classe astratta (abstract class)

Classe che non può essere istanziata. Diverso da: Classe Concreta. [A class that cannot be directly instantiated. Contrast: concrete class.]

classe attiva (active class)

Classe le cui istanze sono oggetti attivi. Vedi: Oggetto Attivo. [A class whose instances are active objects. See: active object.]

classe concreta (concrete class)

Classe che può essere istanziata in modo diretto. Diverso da: Classe Astratta. [A class that can be directly instantiated. Contrast: abstract class.]

classificatore (classifier)

Meccanismo che consente di descrivere proprietà incapsulate di tipo comportamentale e strutturale. Sono classificatori le interfacce, le classi, i tipi di dato e i componenti. [A mechanism that describes behavioral and structural features. Classifiers include interfaces, classes and datatypes and components.]

classificazione dinamica (dynamic classification)

Variante semantica della generalizzazione, in cui un oggetto può mutare tipo o ruolo. Diverso da: Classificazione Statica. [A semantic variation of generalization in which an object may change type or role. Contrast: static classification.]

classificazione multipla (multiple classification)

Variante semantica della generalizzazione, nella quale un oggetto può appartenere direttamente a più di una classe. Vedi: Classificazione Dinamica. [A semantic variation of generalization in which an object may belong directly to more than one class. See: dynamic classification.]

classificazione statica (static classification)

Variante semantica della generalizzazione, nella quale un oggetto non può cambiare tipo o non può cambiare ruolo. Diverso da: Classificazione Dinamica. [A semantic variation of generalization in which an object may not change type or may not change role. Contrast: dynamic classification.]

client (client)

Classificatore che richiede un servizio ad un altro classificatore. Sinonimo: client object [OMA]. Diverso da: Supplier. [A classifier that requests a service from another classifier. Synonym: client object [OMA]. Contrast: supplier.]

collaborazione (collaboration)

La specifica del modo in cui un insieme di classificatori tra loro associati, che rivestono ruoli specifici in uno specifico modo di utilizzo, permettono di realizzare un altro classificatore, come un caso d'uso o un'operazione. La collaborazione definisce un'interazione. Vedi: Interazione. [The specification of how a classifier, such as a use case or operation, is realized by a set of classifiers and associations playing specific roles. used in a specific way. The collaboration defines an interaction. See: interaction.]

commento (comment)

Annotazione collegata ad un elemento o a una collezione di elementi. Una nota non ha rilevanza semantica in termini di metamodello. Diverso da: Costraint. [An annotation attached to an element or a collection of elements. A note has no semantics. Contrast: constraint.]

componente (component)

Modulo software eseguibile, dotato di identità e con un'interfaccia ben specificata. Diverso da: component [OMA]. [An executable software module with identity and a well-defined interface. Contrast: component [OMA].]

comportamento (behavior)

Gli effetti osservabili di un'operazione o di un evento, tra cui i suoi risultati. Sinonimo: behavior [OMA]. [The observable effects of an operation or event, including its results. Synonym: behavior [OMA].]

composita [classe] (composite [class])

Classe che è legata a una o più classi in una relazione di composizione. Vedi:Composizione. [A class that is related to one or more classes by a composition relationship. See: composition.]

composizione (composition)

Forma di aggregazione che comporta un legame molto stretto tra le parti e l'intero, ed un ciclo di vita comune. Le parti con molteplicità non predefinita possono venire create dopo il composito, ma una volta che sono state create vivono e muoiono con esso (cioè ne condividono il ciclo di vita). Le parti possono anche essere rimosse esplicitamente prima della morte del composito. La composizione può essere ricorsiva. Sinonimo:Aggregazione Composita. [A form of aggregation with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of the composite. Composition may be recursive. Synonym: composite aggregation.]

concorrenza (concurrency)

Il fatto che due o più attività avvengano durante il medesimo intervallo temporale. La concorrenza può essere ottenuta intersecando o eseguendo in modo simultaneo due o più thread. Vedi:Thread. [The occurrence of two or more activities during the same time interval. Concurrency can be achieved by interleaving or simultaneously executing two or more threads. See: thread.]

condizione di guardia (guard condition)

Condizione che deve essere soddisfatta per permettere l'innesco (fire) di una transizione, ad essa associata. [A condition that must be satisfied in order to enable an associated transition to fire.]

contenitore (container)

Istanza che esiste per contenere altre istanze, e che mette a disposizione operazioni per accedere o navigare tra i suoi contenuti. Ad esempio, vettori, liste, insiemi. 2. Componente che esiste per contenere altre componenti. [1. An instance that exists to contain other instances, and that provides operations to access or iterate over its contents. For example, arrays, lists, sets. 2. A component that exists to contain other components.]

contesto (context)

Vista di un insieme di elementi di modellazione collegati tra loro per un particolare proposito, come ad esempio la specifica di un'operazione. [A view of a set of related modeling elements for a particular purpose, such as specifying an operation.]

contrassegno temporale (timing mark)

Indica il momento in cui avviene un evento o un messaggio. I contrassegni temporali possono venire utilizzati nell'espressione di vincoli. [A denotation for the time at which an event or message occurs. Timing marks may be used in constraints.]

corsia organizzativa (swimlane)

Partizione di un diagramma di interazione, per organizzare le responsabilità sulle azioni. In un modello di business, corrispondono spesso a unità organizzative. [A partition on interaction diagrams for organizing responsibilities for actions. They often correspond to organizational units in a business model.]

D

delega (delegation)

La capacità di un oggetto di inviare un messaggio ad un altro oggetto in risposta ad un messaggio. La delega può essere utilizzata come un'alternativa all'ereditarietà. Sinonimo: delegation [OMA]. Diverso da:Interfaccia. [The ability of an object to issue a message to another object in response to a message. Delegation can be used as an alternative to inheritance. Synonym: delegation [OMA]. Contrast: inheritance.]

diagramma (diagram)

Presentazione grafica di una collezione di elementi del modello, implementata nella maggioranza dei casi come un grago che connette archi (relazioni) e vertici (altri elementi del modello). UML supporta i seguenti diagrammi: diagramma delle classi, diagramma degli oggetti, diagramma dei casi d'uso, diagramma di sequenza, diagramma di collaborazione, diagramma di stato, diagramma di attività, diagramma dei componenti, diagramma di distribuzione. [A graphical presentation of a collection of model elements, most often rendered as a connected graph of arcs (relationships) and vertices (other model elements). UML supports the following diagrams: class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, and deployment diagram.]

diagramma degli oggetti (object diagram)

Diagramma che evidenzia gli oggetti esistenti in un certo istante, e le relazioni che li legano. Il diagramma degli oggetti può essere considerato come un caso speciale di diagramma delle classi o di diagramma di collaborazione. Vedi: Diagramma delle Classi, Diagramma delle Collaborazioni. [A diagram that encompasses objects and their relationships at a point in time. An object diagram may be considered a special case of a class diagram or a collaboration diagram. See: class diagram, collaboration diagram.]

diagramma dei casi d'uso (use case diagram)

Diagramma che evidenzia le relazioni tra attori e casi d'uso nell'ambito di un sistema. [A diagram that shows the relationships among actors and use cases within a system.]

diagramma dei componenti (component diagram)

Diagramma che evidenzia l'organizzazione e le dipendenze esistenti tra componenti. [A diagram that shows the organizations and dependencies among components.]

diagramma delle classi (class diagram)

Diagramma che mostra una collezione di elementi di modello dichiarativi (statici), come classi e tipi, le loro proprietà e le loro relazioni. [A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.]

diagramma di distribuzione (deployment diagram)

Diagramma che evidenzia la configurazione dei nodi elaborativi in ambiente di esecuzione (run-time), e dei componenti, processi ed oggetti ubicati in questi nodi. I componenti rappresentano manifestazioni di unità di codice in ambiente di esecuzione. Vedi: Diagrammi dei Componenti. [A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units. See: component diagrams.]

diagramma di attività (activity diagram)

Una speciale tipologia di diagramma di stato, in cui tutti gli stati - o la maggior parte - sono stati di azione ed in cui tutte le transizioni - o la maggior parte - sono iniziate dal completamento delle azioni negli stati precedenti. Diverso da:Diagramma di stato. [A special case of a state diagram in which all or most of the states are action states and in which all or most of the of the transitions are triggered by completion of actions in the source states. Contrast: state diagram.]

diagramma di collaborazione (collaboration diagram)

Diagramma che mostra le interazioni che avvengono tra diverse istanze, ed i relativi reciproci legami. A differenza di quanto avviene in un diagramma di sequenza, un diagramma di collaborazione mostra le relazioni esistenti tra le istanze. Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modi diversi. Vedi:Diagramma delle Sequenze. [A diagram that shows interactions organized around instances and their links to each other. Unlike a sequence diagram a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: sequence diagram.]

diagramma di interazione (interaction diagram)

Termine generico, che si applica a più tipi di diagramma che mettono in rilievo le interazioni tra oggetti. Comprendono: diagrammi di collaborazione, diagrammi di sequenza e diagrammi di attività. [A generic term that applies to several types of diagrams that emphasize object interactions. These include: collaboration diagrams, sequence diagrams, and activity diagrams]

diagramma di sequenza (sequence diagram)

Diagramma che evidenzia le interazioni tra oggetti, ordinate in sequenza temporale. Evidenzia, in particolare, gli oggetti che partecipano all'interazione e la sequenza dei messaggi scambiati. A differenza del diagramma di collaborazione, il diagramma di sequenza include le sequenze temporali, ma non le relazioni tra oggetti. Un diagramma di sequenza può esistere in forma generica (descrivendo tutti i possibili scenari) o in forma di istanza (descrivendo un unico scenario effettivo). Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso. Vedi:Diagramma delle Collaborazioni. [A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: collaboration diagram.]

diagramma di stato (statechart diagram)

Diagramma che mostra una macchina di stato. Vedi:Stato Macchina. [A diagram that shows a state machine. See: state machine.]

dipendenza (dependency)

Relazione tra due elementi di modellazione, nella quale un cambiamento ad un elemento di modellazione (l'elemento indipendente) avrà impatto sull'altro elemento di modellazione (l'elemento dipendente). [A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).]

disegno (design)

La parte del processo di sviluppo software il cui obiettivo primario è decidere come verrà implementato il sistema. Nel corso del disegno vengono prese decisioni strategiche e tattiche per soddisfare i requisiti del sistema in termini di funzionalità e di qualità. [The part of the software development process whose primary purpose is to decide how the system will be implemented. During design strategic and tactical decisions are made to meet the required functional and quality requirements of a system.]

documento prodotto (artifact)

Unità di informazione che viene utilizzata o prodotta da un processo di sviluppo software. Può essere un modello, una descrizione, oppure software. [A piece of information that is used or produced by a software development process. An artifact can be a model, a description or software.]

dominio (domain)

Area di conoscenza o di attività caratterizzata da un insieme di concetti e da una terminologia compresi da chi si muove nell'area stessa. [An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area.]

E

elemento (element)

Parte atomica, cioè non scomponibile, di un modello. [An atomic constituent of a model.]

elemento della vista (view element)

Proiezione testuale e/o grafica di una collezione di elementi del modello. [A view element is a textual and/or graphical projection of a collection of model elements.]

elemento del modello (model element)

Elemento che costituisce un'astrazione del sistema in corso di modellazione. Diverso da: Elemento della Vista. [An element that is an abstraction drawn from the system being modeled. Contrast: view element.]

elemento derivato (derived element)

Elemento del modello che può essere calcolato a partire da un altro elemento, ma che viene evidenziato per chiarezza o viene incluso per finalità di disegno anche se non aggiunge informazione sotto il profilo del significato. [A model element that can be computed from another element, but that is shown for clarity or that is included for design purposes even though it adds no semantic information.]

elemento generalizzabile (generalizable element)

Elemento del modello che può partecipare al una relazione di generalizzazione. Vedi: Generalizzazioni. [A model element that may participate in a generalization relationship. See: generalization.]

elemento parametrizzato (parameterized element)

Descrittore di una classe, con uno o più parametri a cui non è stato ancora assegnato un valore. Sinonimo: Modello. [The descriptor for a class with one or more unbound parameters. Synonym: template.]

enumerazione (enumeration)

Lista di valori, ciascuno dei quali identificato da un nome, utilizzata come range per un particolare tipo attributo. Ad esempio, ColoreBase = . Booleano è un'enumerazione predefinita con valori . [A list of named values used as the range of a particular attribute type. For example, RGBColor = . Boolean is a predefined enumeration with the values .]

ereditarietà (inheritance)

Il meccanismo grazie al quale elementi più specifici incorporano struttura e comportamento di elementi più generali, a cui sono legati per aspetti comportamentali. Vedi: Inheritance. Sinonimo: inheritance [OMA]. [The mechanism by which more specific elements incorporate structure and behavior of more general elements related by behavior. See generalization. Synonym: inheritance [OMA].]

ereditarietà dell'implementazione (implementation inheritance)

L'ereditarietà dell'implementazione di un elemento più specifico. Comprende l'ereditarietà dell'interfaccia. Sinonimo: implementation inheritance. Diverso da: interface ineritance. [The inheritance of the implementation of a more specific element. Includes inheritance of the interface. Synonym: implementation inheritance. Contrast: interface inheritance.]

ereditarietà dell'interfaccia (interface inheritance)

L'ereditarietà dell'interfaccia di un elemento più specifico. Non comporta ereditarietà dell'implementazione. Sinonimo: interface inheritance [OMA]. Diverso da: Implementation Inheritance. [The inheritance of the interface of a more specific element. Does not includes inheritance of the implementation. Synonym: interface inheritance [OMA]. Contrast: implementation inheritance.]

ereditarietà multipla (multiple inheritance)

Variante semantica della generalizzazione, nella quale un tipo può avere più di un supertipo. Diverso da: Single Inheritance. [A semantic variation of generalization in which a type may have more than one supertype. Contrast: single inheritance.]

ereditarietà singola (single inheritance)

Variante semantica della generalizzazione, nella quale un tipo può avere solo un supertipo. Sinonimo: multiple inheritance [OMA]. Diverso da: Multiple. [A semantic variation of generalization in which a type may have only one supertype. Synonym: multiple inheritance [OMA]. Contrast: multiple inheritance.

espressione (expression)

Stringa che, risolta, fornisce un valore di un particolare tipo. Ad esempio, l'espressione "(7 + 5 * 3)" fornisce come risultato un valore di tipo numerico. [A string that evaluates to a value of a particular type. For example, the expression "(7 + 5 * 3)" evaluates to a value of type number.]

espressione booleana (boolean expression)

Espressione che fornisce un valore booleano. [An expression that evaluates to a boolean value.]

espressione di azione (action expression)

Espressione che si traduce in una collezione di azioni. [An expression that resolves to a collection of actions.]

espressione di tipo (type expression)

Espressione che, valutata, fornisce come risultato un riferimento ad uno o più tipi. [An expression that evaluates to a reference to one or more types.]

espressione temporale (time expression)

Espressione che, valutata, fornisce come risultato un valore temporale assoluto o relativo. [An expression that resolves to an absolute or relative value of time.]

estremità dell'associazione (association end)

Il punto finale di un'associazione, che connette l'associazione con un classificatore. [The endpoint of an association, which connects the association to a classifier.]

estremità del legame (link end)

Un'istanza di un'estremità dell'associazione. Vedi: Fine Associazione. [An instance of an association end. See: association end.]

evento (event)

La specifica di un avvenimento significativo che avviene in un certo istante e in un certo luogo. Nell'ambito di un diagramma di stato, un evento è un avvenimento che può dare inizio (trigger) ad una transizione di stato. [The specification of a significant occurrence that has a location in time and space. In the context of state diagrams, an event is an occurrence that can trigger a state transition.]

evento temporale (time event)

Evento che denota il tempo trascorso dal momento in cui si è entrati nello stato corrente. Vedi: Evento. [An event that denotes the time elapsed since the current state was entered. See: event.]

export (export)

Nell'ambito di package, il rendere un elemento visibile al di fuori dell'ambito di denominazione (namespace) che lo contiene. Vedi: Visibility. Diverso da: export [OMA], import. [In the context of packages, to make an element visible outside its enclosing namespace. See: visibility. Contrast: export [OMA], import.]

extends (extends)

Relazione che lega un caso d'uso ad un altro, che specifica in quale modo il comportamento definito per il primo caso d'uso può venire inserito nel contesto del coordinamento definito per il secondo caso d'uso. [A relationship from one use case to another, specifying how the behavior defined for the first use case can be inserted into the behavior defined for the second use case.]

F

fase di analisi (analysis time)

Si riferisce a qualcosa che avviene durante la fase di analisi del processo di sviluppo software. Vedi: Design Time, Modelling Time. [Refers to something that occurs during an analysis phase of the software development process. See: design time, modeling time.]

fase di compilazione (compile time)

Si riferisce a qualcosa che avviene durante la compilazione di un modulo software. Vedi: Modellling Time, run Time. [Refers to something that occurs during the compilation of a software module. See: modeling time, run time.]

fase di disegno (design time)

Si riferisce a qualcosa che avviene durante la fase di disegno del processo di sviluppo software. Vedi: Modelling Tyme. Diverso da: Analysis Time. [Refers to something that occurs during a design phase of the software development process. See: modeling time. Contrast: analysis time.]

fase di esecuzione (run time)

Il periodo di tempo nel quale è eseguito un programma. Diverso da: Modelling time. [The period of time during which a computer program executes. Contrast: modeling time.]

fase di modellazione (modeling time)

Si riferisce a qualcosa che avviene durante la fase di modellazione del processo di sviluppo software. Include le fasi di analisi e di disegno. Nota per l'utilizzo: parlando di sistemi a oggetti è spesso importante distinguere tra i problemi inerenti la fase di modellazione e quelli relativi alla fase di esecuzione (run-time). Vedi: Analysis Time, Desing time. Diverso da: run Time. [Refers to something that occurs during a modeling phase of the software development process. It includes analysis time and design time. Usage note: When discussing object systems it is often important to distinguish between modeling-time and run-time concerns. See: analysis time, design time. Contrast: run time.]

framework (framework)

Micro-architettura che mette a disposizione una template estendibile per la realizzazione di applicazioni nell'ambito di uno specifico dominio. [A micro-architecture that provides an extensible template for applications within a specific domain.]

fuoco di controllo (focus of control)

Simbolo su un diagramma di sequenza, che evidenzia il periodo di tempo durante il quale un oggetto sta eseguendo un'azione, direttamente o utilizzando una procedura subordinata. [A symbol on a sequence diagram that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.]

G

generalizzazione (generalization)

Relazione tassonomica tra un elemento più generale ed uno più specifico. L'elemento più specifico corrisponde completamente all'elemento più generale, e contiene informazioni aggiuntive rispetto a quest'ultimo. Un'istanza dell'elemento più specifico può venire utilizzata in ogni ambito in cui è lecita la presenza dell'elemento più generale. Sinonimo: generalization [OMA]. Vedi: inheritance. [A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. Synonym: generalization [OMA]. See: inheritance.]

gerarchia di contenimento (containment hierarchy)

Gerarchia degli ambiti di denominazione che consiste di elementi del modello, e delle relazioni di contenimento che esistono tra loro. Una gerarchia di contenimento forma un grafo aciclico. [A namespace hierarchy consisting of model elements, and the containment relationships that exist between them. A containment hierarchy forms an acyclic graph.]

I

implementazione (implementation)

Definizione del modo in cui qualcosa viene costruito o elaborato. Ad esempio, una classe è un'implementazione di un tipo, un metodo è un'implementazione di un'operazione. Sinonimo: implementation [OMA]. [A definition of how something is constructed or computed. For example, a class is an implementation of a type, a method is an implementation of an operation. Synonym: implementation [OMA].]

import (import)

Nell'ambito di package, 0una dipendenza che evidenzia i package le cui classi possono essere referenziate all'interno di un certo package (comprendendo i package ricorsivamente incorporati all'interno di questo). Diverso da: import [OMA], export. [In the context of packages, a dependency that shows the packages whose classes may be referenced within a given package (including packages recursively embedded within it). Contrast: import [OMA], export.]

innesco di transizione (fire)

Eseguire (dare inizio a, sparare il colpo di inizio a) una transizione di stato. Vedi: Transizione. [To execute a state transition. See: transition.]

interazione (interaction)

Specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico. L'interazione è definita nell'ambito di una collaborazione. Vedi: Collaborazione. [A specification of how messages are sent between instances to perform a specific task. The interaction is defined in the context of a collaboration. See collaboration.]

interfaccia (interface)

Dichiarazione di una collezione di operazioni, che può essere usata per definire un servizio messo a disposizione da un'istanza. Sinonimo: interface [OMA]. [A declaration of a collection of operations that may be used for defining a service offered by an instance. Synonym: interface [OMA].]

inviare [un messaggio] (send [a message])

La trasmissione di un'istanza di messaggio da un oggetto mittente ad uno ricevente. Vedi: Trasmettitore, Ricevente. [The passing of a message instance from a sender object to a receiver object. See: sender, receiver.]

istanza (instance)

Un'entità sulla quale può essere effettuato un insieme di operazioni, e che ha uno stato che memorizza gli effetti delle operazioni. Vedi: Oggetto. [An entity to which a set of operations can be applied and which has a state that stores the effects of the operations. See: object.]

istanza di caso d'uso (use case instance)

L'esecuzione di una sequenza di azioni che è stata specificata in un caso d'uso. Un istanza di un caso d'uso. Vedi: Use case Class. [The performance of a sequence of actions being specified in a use case. An instance of a use case. See: use case class.]

L

legame (link)

Connessione di significato tra una tupla di oggetti. Un'istanza di un'associazione. Sinonimo: link [OMA]. Vedi: Associazione. [A semantic connection among a tuple of objects. An instance of an association. Synonym: link [OMA]. See: association.]

linea di vita dell'oggetto (object lifeline)

In un diagramma di sequenza, linea che rappresenta l'esistenza di un oggetto in un periodo temporale. Vedi: diagramma della Sequenza. [A line in a sequence diagram that represents the existence of an object over a period of time. See: sequence diagram.]

M

macchina di stato (state machine)

Comportamento che specifica le sequenze di stati che un oggetto o un'interazione attraversano nel loro ciclo di vita in risposta ad eventi, e mostra inoltre le risposte e le azioni. [A behavior that specifies the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions.]

messaggio (message)

Specifica di una comunicazione tra istanze, che trasmette informazione nell'aspettativa che ne consegua dell'attività. La ricezione di un'istanza di messaggio viene normalmente considerata un'istanza di un evento. [A specification of a communication between instances that conveys information with the expectation that activity will ensue. The receipt of a message instance is normally considered an instance of an event.]

metaclasse (metaclass)

Classe le cui istanze sono classi. Le metaclassi vengono tipicamente utilizzate per costruire metamodelli. [A class whose instances are classes. Metaclasses are typically used to construct metamodels.]

meta-metamodello (meta-metamodel)

Modello che definisce il linguaggio necessario per esprimere un metamodello. La relazione tra meta-metamodello e metamodello è analoga alla relazione tra un metamodello e un modello. [A model that defines the language for expressing a metamodel. The relationship between a meta-metamodel and a metamodel is analogous to the relationship between a metamodel and a model.]

metamodello (metamodel)

Modello che definisce il linguaggio necessario per esprimere un modello. Un'istanza di un meta-metamodello. [A model that defines the language for expressing a model. An instance of a meta-metamodel.]

metaoggetto (metaobject)

Termine generico che comprende tutte le entità in un linguaggio di metamodellazione. Ad esempio, metatipi, metaclassi, metaattributi, metaassociazioni. Sinonimo: metaobject [OMA]. [A generic term for all metaentities in a metamodeling language. For example, metatypes, metaclasses, metaattributes, and metaassociations. Synonym: metaobject [OMA].]

metodo (method)

Implementazione di un'operazione. Specifica l'algoritmo o procedura che produce i risultati di un'operazione. Sinonimo: method [OMA]. [The implementation of an operation. It specifies the algorithm or procedure that effects the results of an operation. Synonym: method [OMA].]

mittente [oggetto] sender [object]

L'oggetto che trasmette un'istanza di messaggio ad un oggetto ricevente. Diverso da: Ricevente. [The object passing a message instance to a receiver object. Contrast: receiver.]

modello (model)

Astrazione semanticamente chiusa di un sistema. Vedi: Sistema. [A semantically closed abstraction of a system. See: system.]

modello dei casi d'uso (use case model)

Modello che descrive i requisiti funzionali di un sistema in termini di casi d'uso. [A model that describes a system's functional requirements in terms of use cases.]

modulo (module)

Unità software di memorizzazione e manipolazione. Sono moduli i moduli di codice sorgente, i moduli di codice binario, i moduli di codice eseguibile. Vedi: Componente. [A software unit of storage and manipulation. Modules include source code modules, binary code modules, and executable code modules. See: component.]

molteplicità (multiplicity)

Specifica del range di cardinalità ammissibili che un insieme può assumere. Le specifiche di molteplicità possono riferirsi a ruoli nell'ambito di associazioni, a parti nell'ambito di compositi, ripetizioni, e anche altri ambiti. Nella sua essenza, una molteplicità costituisce un sottoinsieme (eventualmente infinito) degli interi non negativi. Diverso da: Cardinalità. [A specification of the range of allowable cardinalities that a set may assume. Multiplicity specifications may be given for roles within associations, parts within composites, repetitions, and other purposes. Essentially a multiplicity is a (possibly infinite) subset of the non-negative integers. Contrast: cardinality.]

N

nodo (node)

E' un oggetto fisico, esistente in fase di esecuzione (run-time), che rappresenta una risorsa elaborativa, dotata in genere almeno di una memoria, ma spesso anche di propria capacità elaborativa. In fase di esecuzione, oggetti e componenti possono essere allocati all'interno di nodi. [A node is a run-time physical object that represents a computational resource, generally having at least a memory and often processing capability as well. Run-time objects and components may reside on nodes.]

nome (name)

Stringa utilizzata per identificare un elemento del modello. [A string used to identify a model element.]

non interpretato (uninterpreted)

Segnaposto per un tipo o dei tipi la cui implementazione non è specificata da UML. Ogni valore non interpretato ha una corrispondente rappresentazione in formato stringa, Vedi: any [CORBA]. [A placeholder for a type or types whose implementation is not specified by the UML. Every uninterpreted value has a corresponding string representation. See: any [CORBA].]

O

oggetto (object)

Entità ben delimitata, e dotata di un'identità che incapsula stato e comportamento. Lo stato è rappresentato da attributi e relazioni, il comportamento da operazioni, metodi e macchine di stato. Un oggetto è un'istanza di una classe. Sinonimo: object [OMA]. Vedi: Classe, Istanza. [An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations, methods, and state machines. An object is an instance of a class. Synonym: object [OMA]. See: class, instance.]

oggetto attivo (active object)

Oggetto che possiede un thread e può iniziare un'attività di controllo. Un'istanza di una classe attiva. Vedi: Classe Attiva, Thread. [An object that owns a thread and can initiate control activity. An instance of active class. See: active class, thread.]

oggetto persistente (persistent object)

Oggetto che prosegue la sua esistenza anche dopo che il processo o il thread che l'hanno creato hanno a loro volta cessato di esistere. Sinonimo: persistent object [OMA]. [An object that exists after the process or thread that created it has ceased to exist. Synonym: persistent object [OMA].]

oggetto transitorio (transient object)

Oggetto che esiste solo durante l'esecuzione del processo o del thread che lo ha creato. Sinonimo: transient object [OMA]. [An object that exists only during the execution of the process or thread that created it. Synonym: transient object [OMA].]

operazione (operation)

Servizio che può essere richiesto ad un oggetto per fare qualcosa. Ogni operazione ha una segnatura, che può vincolare i parametri effettivi possibili. Sinonimo: operation [OMA]. [A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. Synonym: operation [OMA].]

P

package (package)

Meccanismo generalizzato per organizzare elementi in gruppi. E' possibile nidificare package all'interno di altri package. Un sistema può essere pensato come un singolo package di alto livello, comprendente tutte le altre componenti del sistema stesso. [A general purpose mechanism for organizing elements into groups. Packages may be nested within other packages. A system may be thought of as a single high-level package, with everything else in the system contained in it.]

parametro (parameter)

Specifica di una variabile che può essere modificata, passata o ricevuta in ritorno. I parametri possono avere un nome, un tipo e una direzione. I parametri sono utilizzati per operazioni, messaggi e eventi. Sinonimi: parameter [OMA],Parametro Formale. Diverso da: Argomento. [The specification of a variable that can be changed, passed or returned. A parameter may include a name, type and direction. Parameters are used for operations, messages and events. Synonyms: parameter [OMA], formal parameter. Contrast: argument.]

parametro effettivo (actual parameter)

Sinonimo: Argomento. [Synonym: argument.]

parametro formale (formal parameter)

Sinonimo: Parametro. [Synonym: parameter.]

participates (participates)

Una relazione che indica il ruolo svolto da un'istanza in un elemento di modellazione. Ad esempio, una classe partecipa ad un'associazione, un attore partecipa ad un caso d'uso. Diverso da: participate [OMA]. [A relationship that indicates the role that an instance plays in a modeling element. For example, a class participates in an association, an actor participates in a use case. Contrast: participate [OMA].]

postcondizione (postcondition)

Vincolo che deve risultare rispettato al completamento di un'operazione. [A constraint that must be true at the completion of an operation.]

precondizione (precondition)

Vincolo che deve risultare rispettato al momento del richiamo di un'operazione. [A constraint that must be true when an operation is invoked.]

processo (process)

Un thread che può essere eseguito in modo concorrente con altri thread. [A thread that can execute concurrently with other threads.]

processo di sviluppo (development process)

Insieme di passi parzialmente ordinati, eseguiti per uno scopo particolare, come ad esempio la costruzione di modelli o l'implementazione di modelli, durante lo sviluppo del software. [A set of partially ordered steps performed for a given purpose during software development, such as constructing models or implementing models.]

prodotto (product)

I documenti prodotti dallo sviluppo, come modelli, codice, documentazione, piani di lavoro. [The artifacts of development, such as models, code, documentation, work plans.]

proiezione (projection)

La corrispondenza (mapping) tra un insieme ed un suo sottoinsieme. [A mapping from a set to a subset of it.]

proiezione su vista (view projection)

Proiezione di elementi del modello su elementi della vista. Le proiezioni su vista forniscono coordinate spaziali e stile a ciascun elemento della vista. [A projection of model elements onto view elements. A view projection provides a location and a style for each view element.]

proprietà (property)

Valore a cui è associato un nome, che denota una caratteristica di un elemento. Le proprietà hanno valenza semantica. Alcune proprietà sono predefinite in UML; altre possono venire definite dall'utilizzatore. Vedi: Tagged Value. Sinonimo: property [OMA]. [A named value denoting a characteristic of an element. A property has semantic impact. Certain properties are predefined in the UML; others may be user defined. See: tagged value. Synonym: property [OMA].]

proprietà incapsulata (feature)

Proprietà, come un'operazione o un attributo, incapsulata all'interno di un'altra entità, come un'interfaccia, una classe o un tipo di dato. [A property, like operation or attribute, which is encapsulated within another entity, such as an interface, a class or a datatype.]

proprietà incapsulata di comportamento (behavioral feature)

Una proprietà incapsulata di tipo dinamico di un elemento del modello, come un'operazione o un metodo. [A dynamic feature of a model element, such as an operation or method.]

proprietà incapsulata strutturale (structural feature)

Proprietà incapsulata di tipo statico di un elemento del modello, come ad esempio un attributo. [A static feature of a model element, such as an attribute.]

pseudostato (pseudo-state)

Vertice in una macchina di stato che ha forma di stato, ma non i comportamenti di uno stato. Comprendono i pseudostati iniziale, finale e storico. [A vertex in a state machine that has the form of a state, but doesn't behave as a state. Pseudo-states include initial, final, and history vertices.]

punto di variazione semantica (semantic variation point)

Un punto di variazione nella semantica di un metamodello. Fornisce un grado di libertà intenzionale per l'interpretazione dei significati del metamodello. [A point of variation in the semantics of a metamodel. It provides an intentional degree of freedom for the interpretation of the metamodel semantics.]

Q

qualificatore (qualifier)

Attributo (o tupla di attributi) di un'associazione, i cui valori partizionano l'insieme di oggetti collegati ad un oggetto mediante l'associazione. [An association attribute or tuple of attributes whose values partition the set of objects related to an object across an association.]

R

raffinamento (refinement)

Relazione che rappresenta una specifica più completa di qualcosa che era già stato specificato ad un certo livello di dettaglio. Ad esempio, una classe in disegno è un raffinamento di una classe in analisi. [A relationship that represents a fuller specification of something that has already been specified at a certain level of detail. For example, a design class is a refinement of an analysis class.]

relazione (relationship)

Connessione semantica tra elementi del modello. Tra gli esempi, associazioni e generalizzazioni. [A semantic connection among model elements. Examples of relationships include associations and generalizations.]

repository (repository)

Luogo di memorizzazione per modelli a oggetti, interfacce ed implementazioni. [A storage place for object models, interfaces and implementations.]

requisito (requirement)

Caratteristica, proprietà o comportamento desiderato per un sistema. [A desired feature, property, or behavior of a system.]

responsabilità (responsibility)

Contratto o impegno, in carico a un tipo o classe. [A contract or obligation of a type or class.]

ricevente [oggetto] (receiver [object])

L'oggetto che tratta un'istanza di messaggio che ha ricevuto da un oggetto mittente. Diverso da: Trasmettitore. [The object handling a message instance passed from a sender object. Contrast: sender.]

ricevere [un messaggio] (receive [a message])

Il trattamento di un'istanza di messaggio ricevuta da un oggetto mittente. Vedi: Trasmettitore, Ricevente. [The handling of a message instance passed from a sender object. See: sender, receiver.]

richiesta (request)

La specifica di uno stimolo inviato ad istanze. Può essere un'operazione o un segnale. [A request is the specification of a stimulus being sent to instances. It can be either an operation or a signal.]

riferimento (reference)

Denotazione di un elemento del modello. 2. Proprietà di un classificatore, identificata con un nome, che facilita la navigazione verso altri classificatori. [1. A denotation of a model element. 2. A named slot within a classifier that facilitates navigation to other classifiers.]

riutilizzo (reuse)

L'uso di un documento prodotto preesistente. [The use of a pre-existing artifact.]

ruolo (role)

Comportamento specifico, a cui è stato assegnato un nome, di un'entità che partecipa ad un certo contesto. I ruoli possono essere statici (ad esempio, l'estremità di un'associazione) o dinamici (ad esempio, un ruolo in una collaborazione). [The named specific behavior of an entity participating in a particular context. A role may be static (e.g., an association end) or dynamic (e.g., a collaboration role).]

S

scenario (scenario)

Sequenza specifica di azioni che mette in luce un comportamento. Uno scenario può venire utilizzato per illustrare un'interazione. Vedi: interazione. [A specific sequence of actions that illustrates behaviors. A scenario may be used to illustrate an interaction. See: interaction.]

segnale (signal)

Specifica di uno stimolo asincrono, comunicato tra istanze. I segnali possono avere parametri. [The specification of an asynchronous stimulus communicated between instances. Signals may have parameters.]

segnatura (signature)

Il nome ed i parametri di una proprietà incapsulata di tipo comportamentale. Le segnature possono includere un parametro di ritorno opzionale. Sinonimo: signature [OMA]. [The name and parameters of a behavioral feature. A signature may include an optional returned parameter. Synonym: signature [OMA].]

sistema (system)

Collezione di unità connesse, organizzate per un obiettivo specifico. Un sistema può essere descritto da uno o più modelli, anche corrispondenti a diversi punti di osservazione. [A collection of connected units that are organized to accomplish a specific purpose. A system can be described by one or more models, possibly from different viewpoints.]

sottoclasse (subclass)

In una relazione di generalizzazione, è la specializzazione di un'altra classe, la superclasse. Vedi: Generalizzazione. Diverso da: Superclasse. [In a generalization relationship the specialization of another class, the superclass. See: generalization. Contrast: superclass.]

sottosistema (subsystem)

Raggruppamento di elementi del modello, alcuni dei quali costituiscono una specifica del comportamento offerto dagli altri elementi del modello contenuti nel sottosistema. Vedi: Package. Diverso da: System. [A subsystem is a grouping of model elements, of which some constitute a specification of the behavior offered by the other contained model elements. See package. Contrast: system.]

sottostato (substate)

Stato che è parte di uno stato composito. Vedi: Concurrent State, disjoint State. [A state that is part of a composite state. See: concurrent state, disjoint state.]

sottostato concorrente (concurrent substate)

Sottostato che può essere valido nello stesso momento in cui sono validi altri sottostati facenti parte del medesimo stato composito. Vedi: stato composito. Diverso da: disjoint Substate. [A substate that can be held simultaneously with other substates contained in the same composite state. See: composite state. Contrast: disjoint substate.]

sottostato disgiunto (disjoint substate)

Sottostato che non può essere valido contemporaneamente ad altri sottostati contenuti nel medesimo stato composito. Vedi: Composite State. Diverso da: Concurrent Substate. [A substate that cannot be held simultaneously with other substates contained in the same composite state. See: composite state. Contrast: concurrent substate.]

sottotipo (subtype)

In una relazione di generalizzazione, la specializzazione di un altro tipo, il supertipo. Vedi: Generalizzazione. Diverso da: supertipo. [In a generalization relationship the specialization of another type, the supertype. See: generalization. Contrast: supertype.]

specifica (specification)

Descrizione dichiarativa di ciò che qualcosa è o fa. Diverso da: implementation. [A declarative description of what something is or does. Contrast: implementation.]

stato (state)

Condizione o situazione nel corso della vita di un oggetto, durante la quale esso soddisfa alcune condizioni, effettua alcune attività, resta in attesa di determinati eventi. Diverso da: state [OMA]. [A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. Contrast: state [OMA].]

stato composito (composite state)

Stato che consiste di sottostati concorrenti o di sottostati disgiunti. Diverso da: substate. [A state that consists of either concurrent substates or disjoint substates. Contrast: substate.]

stato di azione (action state)

Stato che rappresenta l'esecuzione di un'azione atomica, tipicamente un'operazione. [A state that represents the execution of an atomic action, typically the invocation of an operation.]

stereotipo (stereotype)

Nuovo tipo di elemento di modellazione, che estende le potenzialità emantiche del metamodello. Gli stereotipi devono essere basati su alcuni tipi o classi esistenti nel metamodello. Possono estendere i significati, ma non la struttura dei tipi o delle classi preesistenti. Alcuni stereotipi sono predefiniti in UML, altri possono essere definiti dall'utilizzatore. Gli stereotipi costituiscono uno dei tre meccanismi di estendibilità di UML. Vedi: Constraint, tagged Value. [A new type of modeling element that extends the semantics of the metamodel. Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are predefined in the UML, others may be user defined. Stereotypes are one of three extendibility mechanisms in UML. See: constraint, tagged value.]

strato (layer)

Modo specifico di raggruppare, in un modello, package che si trovano allo stesso livello di astrazione. [A specific way of grouping packages in a model at the same level of abstraction.]

stringa (string)

Sequenza di caratteri testuali. I dettagli di rappresentazione delle strinche dipendono dall'implementazione, e possono includere insiemi di caratteri per il supporto di caratteri internazionali ed elementi grafici. [A sequence of text characters. The details of string representation depend on implementation, and may include character sets that support international characters and graphics.]

superclasse (superclass)

In una relazione di generalizzazione, la generalizzazione di un'altra classe, la sottoclasse. Vedi: Generalizzazione. Diverso da: subclasse. [In a generalization relationship the generalization of another class, the subclass. See: generalization. Contrast: subclass.]

supertipo (supertype)

In una relazione di generalizzazione, la generalizzazione di un altro tipo, il supertipo. Sinonimo: supertype [OMA]. Vedi: Generalizzazione. Diverso da: subtipo. [In a generalization relationship the generalization of another type, the subtype. Synonym: supertype [OMA]. See: generalization. Contrast: subtype.]

supplier (supplier)

Un tipo, classe o componente che mette a disposizione servizi richiamabili da altri. Sinonimo: server object [OMA]. Diverso da: client. [A type, class or component that provides services that can be invoked by others. Synonym: server object [OMA]. Contrast: client.]

T

template (template)

Sinonimo: Elemento parametrizzato. [Synonym: parameterized element.]

tempo (time)

Valore che rappresenta un momento temporale, assoluto o relativo. [A value representing an absolute or relative moment in time.]

thread [di controllo] (thread [of control])

Singolo cammino di esecuzione attraverso un programma, un modello dinamico, o qualche altra rappresentazione di un flusso di controllo. Vedi: processo. [A single path of execution through a program, a dynamic model, or some other representation of control flow. See process.]

tipo (type)

Stereotipo, o classe, utilizzato per specificare un dominio di istanze (oggetti), insieme alle operazioni applicabili a tali oggetti. I tipi possono non contenere metodi. Sinonimo: type [OMA]. Vedi: Classe, Istanza. Diverso da: interfaccia. [A stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects. A type may not contain any methods. Synonym: type [OMA]. See: class, instance. Contrast: interface.]

tipo di dato (datatype)

Un tipo i cui valori sono privi di identità. Tra i tipi di dato sono compresi i tipi primitivi predefiniti (built-in, come numeri e stringhe di caratteri), così come i tipi basati su enumerazioni (come i booleani). [A type whose values have no identity. Datatypes include primitive built-in types (such as numbers and strings) as well as enumeration types (such as boolean).]

tipo primitivo (primitive type)

Tipo di base predefinito, come un intero o una stringa. [A predefined basic type, such as an integer or a string.]

traccia (trace)

Dipendenza che indica una relazione storica o di processo tra due elementi che rappresentano il medesimo concetto, quando non esistano regole specifiche per derivare l'uno dall'altro. [A dependency that indicates a historical or process relationship between two elements that represent the same concept without specific rules for deriving one from the other.]

transizione (transition)

Relazione tra due stati, indicante il fatto che un oggetto che si trova nel primo stato effettuerà certe azioni specificate, e passerà nel secondo stato, nel momento in cui avviene uno specifico evento e sono soddisfatte specifiche condizioni. In tale cambiamento di stato si dice che la transizione viene innescata (fire). [A relationship between two states indicating that an object in the first state will perform certain specified actions and enter the second state when a specified event occurs and specified conditions are satisfied. On such a change of state the transition is said to fire.]

U

unità di distribuzione (distribution unit) Un insieme di oggetti o componenti allocati unitariamente ad un processo o a un processore. Un'unità di distribuzione può venire rappresentata da un composito o da un aggregato in fase di esecuzione (run-time). [A set of objects or components that are allocated to a process or a processor as a group. A distribution unit can be represented by a run-time composite or an aggregate.]

uses (uses)

Relazione tra un caso d'uso e un altro caso d'uso, nella quale il comportamento definito per il primo caso d'uso utilizza il comportamento definito per il secondo. [A relationship from a use case to another use case in which the behavior defined for the former use case employs the behavior defined for the latter.]

utility (utility)

Stereotipo che raggruppa variabili globali e procedura sotto forma di una dichiarazione di classe. Attributi e operazioni di una utility diventano rispettivamente variabili globali e procedure globali. Le utility non costituiscono un costrutto di modellazione fondamentale, ma un espediente di programmazione. [A stereotype that groups global variables and procedures in the form of a class declaration. The utility attributes and operations become global variables and global procedures, respectively. A utility is not a fundamental modeling construct but a programming convenience.]

utilizzo (usage)

Dipendenza in cui un elemento (il client) richiede la presenza di un altro elemento (il supplier) per il proprio corretto funzionamento o implementazione. [A dependency in which one element (the client) requires the presence of another element (the supplier) for its correct functioning or implementation.]

V

valore (value)

Elemento del dominio di un tipo. Diverso da: value [OMA]. [An element of a type domain. Contrast: value [OMA].]

valore etichettato (tagged value)

Definizione esplicita di una proprietà in termini di coppia nome-valore. In un valore etichettato, il nome costituisce l'etichetta. Alcune etichette sono predefinite in UML; altre possono venire definite dall'utilizzatore. I valori etichettati costituiscono uno dei tre meccanismi di estendibilità di UML. Vedi: constraint, stereotype. [The explicit definition of a property as a name-value pair. In a tagged value, the name is referred as the tag. Certain tags are predefined in the UML; others may be user defined. Tagged values are one of three extendibility mechanisms in UML. See: constraint, stereotype.]

vertice (vertex)

La sorgente o la destinazione di una transizione in una macchina di stato. Un vertice può essere o uno stato oppure un pseudostato. Vedi: Stato, pseudo-stato. [A source or a target for a transition in a state machine. A vertex can be either a state or a pseudo-state. See: state, pseudo-state.]

vincolo (constraint)

Condizione semantica, o restrizione. Alcuni vincoli sono predefiniti a livello di UML, altri possono essere definiti dall'utilizzatore di UML. I vincoli costituiscono uno dei tre meccanismi di estensione di UML. Vedi: Tagged Value, Stereotype. [A semantic condition or restriction. Certain constraints are predefined in the UML, others may be user defined. Constraints are one of three extendibility mechanisms in UML. See: tagged value, stereotype.]

visibilità (visibility)

Enumerazione il cui valore (pubblico, protetto, privato) specifica in che misura l'elemento del modello a cui è riferito può essere visto al di fuori dell'ambito di denominazione in cui è inserito. [An enumeration whose value (public, protected, or private) denotes how the model element to which it refers may be seen outside its enclosing namespace.]

vista (view)

Proiezione di un modello, osservata da una certa prospettiva o punto di vista, che omette entità non rilevanti per tale prospettiva. [A projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.]

6.7 OCL

Questa piccola appendice fornisce una brave e generica spiegazione di cosa è OCL. Lo strumento OCL è ampliamente descritto nella sua sintassi e nelle sue operazioni nella sezione OCL del manuale UML.

OCL (Object Constraint Language) è un linguaggio usato dagli utenti dell'UML e di altri standard per specificare le espressioni riguardanti I modelli utilizzati. Ad esempio OCL è usato nel documento UML Semantics per specificare le regole di forma di un metamodello. Ogni regola nella sezione di semantiche statiche nel documento UML Semantics contiene un'espressione OCL. La grammatica dell'OCL è specificata nel documento UML OCL del manuale.

OCL è' stato inserito per la specificazione di regole all'interno dello sviluppo attraverso lo standard UML perché un modello grafico, come ad esempio un Class Model, non era ritenuto sufficientemente chiaro e completo. C'era la necessità di descrivere regole addizionali per gli oggetti nel modello. Inizialmente questo veniva fatto in lingua d'uso corrente, il risultato continuava però ad essere ambiguo. Questa ambiguità è stata superata con la costruzione di un linguaggio di tipo formale, che certamente risulta di più difficile uso, ma che permette la descrizione adeguata di sistemi anche complessi.

Le istruzioni OCL sono state costruite in modo da garantire l'assenza assoluta di influenze sul modello che si stà sviluppando. Uno stato di un progetto non può quindi cambiare per effetto di un'istruzione OCL, eventualmente il cambiamento di stato di un modello potrà essere descritto attraverso un'istruzione OCL.

SOFTWARE USATO

Acrobat Exchange. Necessario per poter leggere i files contenuti nel CD-ROM di UML, con estensione .PDF, formato spesso utilizzato per la stesura di manuali o di articoli specializzati.

ItalWin. Traduttore di lingua inglese, reperito da privati, distribuito dall'Italian Assistant. Necessario per la traduzione del manuale UML da lingua inglese a italiano.

Trascend. Traduttore di lingua inglese, reperito da privati. Necessario per la traduzione del manuale UML da lingua inglese a italiano.

Microsoft Word. Utilizzato la stesura del progetto e per fornire un suo primo abozzo ai docenti cooperatori. Utilizzato anche per la conversione dei files .PDF non interpretabili direttamente dai traduttori di software.

BIBLIOGRAFIA

Articolo Introduzione all'ingegneria del software di Lorenzo vandoni uscito con la prima parte sul numero 9 (Ottobre 98) della rivista Programmo Subito. Le successive tre parti dell'articolo sono state pubblicate rispettivamente nei numeri 10, 11, 12.

Manuale dell'Unified Modelling Language fornito dalla sede italiana dell'azienda software Rational. Il manuale include i documenti utilizzati nello sviluppo del progetto fra i quali UML summary, UML Semantics, UML OCL.

Software per lo sviluppo Rational Rose 98 scaricato dal sito ufficiale dell'azienda produttrice Rational www.Rational.com.

Software di traduzione ItalWin reperito da privato, incluso in un cd demo di una rivista software.

Software di traduzione Trascend Natural Language Translator scaricato dal sito internet con indirizzo www.languagepartners.com

Documentazione aggiuntiva riguardante i prodotti basati sull'UML o riguardanti la storiografia e altre informazioni generali sullo standard sono stati reperiti dai segenti siti internet:

www.AnalisiDisegno.com

www.Rational.com

Ringraziamenti: si ringraziano i docenti e gli studenti che hanno fornito un aiuto allo sviluppo del progetto e al riperimento del materiale necessario. Ringraziamenti anche alla sede italiana della società Rational per l'invio di materiale specifico riguardante i suoi prodotti in seguito al nostro constatato interessamento.