Storia dell'UML

Lo sviluppo di UML iniziò nell'ottobre 1994, quando Grady Booch e Jim Rumbaugh di Rational Software Corporation iniziarono a lavorare insieme per unificare i metodi Booch e OMT (Object Modeling Technique). Entrambi i metodi si sono sviluppati indipendentemente l'uno dall'altro e sono stati giustamente definiti uno dei migliori metodi dell'approccio orientato agli oggetti nello sviluppo di sistemi software. Si decise di combinare questi due metodi e nell'ottobre 1995 fu rilasciata una versione beta, chiamata Metodo Unificato.

Alla fine del 1996 divenne chiaro che un certo numero di grandi aziende erano pronte a considerare l’UML come una strategia aziendale fondamentale. È stato creato un consorzio senza scopo di lucro OMG (Object Modeling Group), che ha unito i principali produttori di software come DEC, HP, IBM, Microsoft, Oracle, Rational Software, ecc. Nel gennaio 1997 è stato rilasciato UML 1.0. Ben presto aziende come IBM, Objectime, Platinum Technology e Softeam si unirono a OMG. Come risultato di questa collaborazione è apparso UML 1.1. Nel 2003 è stata adottata la versione 1.5. 2004 – adottata la versione 2.0

Struttura UML

UML (abbreviazione di Unified Modeling Language) è un linguaggio di descrizione grafica per la modellazione di oggetti nel campo dello sviluppo di software. UML è un linguaggio generale, uno standard aperto che utilizza la notazione grafica per creare un modello astratto di un sistema, chiamato modello UML. UML è stato creato per definire, visualizzare, progettare e documentare la maggior parte dei sistemi software.

UML fornisce lo sviluppo di modelli rappresentativi per organizzare l'interazione tra il cliente e lo sviluppatore IS e vari gruppi di sviluppatori IS.

Innanzitutto UML eredita le tecniche da Booch, OMT e OOSE.

In secondo luogo, li copre.

In terzo luogo, va notato che UML è uno standard linguistico, non uno standard di processo.

Il linguaggio UML include un insieme di elementi grafici utilizzati nei diagrammi. Come linguaggio, UML contiene regole per combinare questi elementi. I diagrammi vengono utilizzati per mostrare diverse visualizzazioni di un sistema. Questo insieme di diverse rappresentazioni è chiamato modello. Il modello UML descrive cosa dovrà fare il sistema. Allo stesso tempo, non viene detto nulla su come verrà implementato.

Dal punto di vista più generale, la descrizione del linguaggio UML è composta da due parti interagenti, quali:

Semantica del linguaggio UML. Rappresenta un certo metamodello che definisce la sintassi astratta e la semantica dei concetti di modellazione di oggetti nel linguaggio UML.

Notazione UML. È una notazione grafica per rappresentare visivamente la semantica del linguaggio UML.

Diagrammi UML

Passiamo ora ad una panoramica della notazione grafica UML. La notazione grafica è una mappatura della rappresentazione visiva nella semantica di un linguaggio. Come accennato in precedenza, UML è la quintessenza delle tre tecniche di modellazione, e ne eredita essenzialmente la notazione grafica, scartando elementi poco utilizzati e inespressivi e aggiungendone di nuovi per soddisfare le esigenze del moderno mercato dei sistemi software. Durante la creazione di UML, abbiamo cercato di mantenere un equilibrio tra la semplicità e la comprensibilità del linguaggio e la sua forza espressiva e precisione. Il modello del sistema in fase di sviluppo è un insieme di sottomodelli interconnessi, ciascuno dei quali è descritto da un insieme di diagrammi descritti utilizzando una notazione grafica definita in UML.

Un progetto creato utilizzando UML 1.x può includere i seguenti diagrammi (raggruppati in base al loro scopo): Ci sono tali diagrammi otto:

Diagramma dei casi d'uso

· Diagramma delle classi

· Diagrammi di comportamento

o Diagramma del diagramma di stato

o Diagramma delle attività

o Diagrammi di interazione

§ Diagramma di sequenza

§ Diagramma di collaborazione

· Diagrammi di implementazione

o Schema dei componenti

o Diagramma di distribuzione

3.1. Diagramma dei casi d'uso

I diagrammi di utilizzo descrivono la funzionalità dell'IS che sarà visibile agli utenti del sistema. "Ogni funzionalità" è descritta come "casi d'uso" o semplicemente casi d'uso. Un caso d'uso è una tipica interazione dell'utente con il sistema, che:

descrive una funzione visibile all'utente,

può rappresentare diversi livelli di dettaglio,

garantisce il raggiungimento di un obiettivo specifico importante per l'utente.

Un caso d'uso è indicato nel diagramma da un ovale associato agli utenti, solitamente chiamati attori. Gli attori utilizzano il sistema (o sono utilizzati dal sistema) in un dato caso d'uso. L'attore svolge un ruolo in questo caso d'uso. Il diagramma raffigura un solo attore, ma potrebbero esserci molti utenti reali che agiscono in questo ruolo in relazione all'IS. L'elenco di tutti i precedenti determina infatti i requisiti funzionali del sistema informativo, che costituiscono la base per lo sviluppo delle specifiche tecniche per la realizzazione del sistema.

Nei diagrammi dei casi d'uso, oltre alle connessioni tra attori e casi d'uso, è possibile utilizzare altri due tipi di connessioni tra casi d'uso: “uso” ed “estensione” (Fig. 3.1.1). Una connessione di tipo estensione viene utilizzata quando un caso d'uso è simile a un altro, ma comporta un carico funzionale leggermente maggiore. Dovrebbe essere usato per descrivere i cambiamenti nel normale comportamento di un sistema. Una connessione di tipo “uso” consente di isolare un determinato frammento del comportamento del sistema e includerlo in vari casi d'uso senza ridescriverlo.

Il nucleo del ruolo di UML nello sviluppo del software è la varietà di modi in cui può essere utilizzato, differenze che sono state trasferite da altri linguaggi di modellazione grafica. Queste differenze portano a discussioni lunghe e difficili su come applicare UML.

Per risolvere questa difficile situazione, Steve Mellor e Martin Fowler hanno elaborato indipendentemente la definizione tre modalità di utilizzo di UML dagli sviluppatori: modalità schizzo, modalità progetto e modalità linguaggio di programmazione. Naturalmente, la più importante delle tre è la modalità di utilizzo. UML per lo sketch. In questa modalità, gli sviluppatori utilizzano UML per comunicare informazioni su vari aspetti del sistema. In modalità progettazione è possibile utilizzare gli schizzi per il forward engineering e il reverse engineering. A sviluppo diretto(ingegneria avanzata) i diagrammi vengono disegnati prima della codifica e quando ingegneria inversa(ingegneria inversa) i diagrammi sono costruiti in base al codice sorgente per comprenderlo meglio.

L'essenza dello schizzo o modellazione di schizzi, nella selettività. Nello sviluppo diretto, abbozzi i singoli elementi del programma che intendi scrivere e di solito li discuti con alcuni sviluppatori del tuo team. Con gli schizzi, vuoi rendere più semplice la condivisione di idee e opzioni per ciò che farai. Non si discute dell'intero programma su cui si intende lavorare, ma solo dei punti più importanti che si vogliono trasmettere prima ai colleghi, o delle sezioni del progetto che si vogliono visualizzare prima dell'inizio della programmazione. Questi incontri possono essere molto brevi: una riunione di 10 minuti per coprire alcune ore di programmazione o una riunione di un giorno per discutere un'iterazione di due settimane.

Nel reverse engineering, usi gli schizzi per spiegare come funziona una parte di un sistema. Non mostri tutte le classi, solo quelle che interessano e che vale la pena discutere prima di immergersi nel codice. Poiché lo schizzo è un'attività informale e dinamica ed è necessario farlo in modo rapido e collaborativo, il miglior mezzo di visualizzazione è una lavagna. Gli schizzi sono utili anche nella documentazione, dove il processo di trasmissione delle informazioni piuttosto che la completezza gioca un ruolo importante. Gli strumenti di schizzo sono strumenti di disegno leggeri e spesso gli sviluppatori non aderiscono realmente a tutte le rigide regole di UML. La forza degli schizzi sta nella selettività del trasferimento delle informazioni e non nella completezza della descrizione.

Al contrario, la lingua UML Come significa progetto finalizzato alla completezza. Nel processo di sviluppo diretto, l'idea è che il progetto venga sviluppato da un designer il cui compito è costruire un modello dettagliato per il programmatore che eseguirà la codifica. Un modello di questo tipo dovrebbe essere abbastanza completo in termini di decisioni di progettazione stabilite e il programmatore dovrebbe essere in grado di seguirle direttamente e senza pensarci troppo. Il progettista del modello può essere lo stesso programmatore, ma, di norma, il progettista è un programmatore senior che sviluppa modelli per il team di programmazione. La ragione di questo approccio risiede nell'analogia con altri tipi di lavori di ingegneria, in cui ingegneri professionisti creano disegni che vengono poi consegnati alle imprese di costruzione.

È possibile utilizzare la progettazione per tutte le parti del sistema oppure il progettista può disegnare un modello di una parte specifica. Un approccio comune prevede che il progettista sviluppi modelli a livello di progettazione come interfacce di sottosistema e poi lasci che gli sviluppatori lavorino sui dettagli di implementazione.

Nel reverse engineering, lo scopo dei modelli è rappresentare informazioni dettagliate su un programma sotto forma di documenti cartacei o in una forma adatta alla visualizzazione interattiva utilizzando un browser grafico. In un modello di questo tipo, puoi mostrare tutti i dettagli di una classe in una forma grafica più semplice da comprendere per gli sviluppatori.

La modellazione richiede strumenti più sofisticati rispetto allo schizzo perché è necessario mantenere i dettagli che soddisfino i requisiti dell'attività. Gli strumenti CASE specializzati (ingegneria del software assistita da computer) rientrano in questa categoria, sebbene il termine stesso sia diventato quasi una parolaccia e i fornitori cerchino di evitarlo. Gli strumenti di sviluppo diretto supportano il disegno di diagrammi e la loro copia in un repository allo scopo di archiviare informazioni. Gli strumenti di reverse engineering leggono il codice sorgente, scrivono la sua interpretazione in un repository e generano diagrammi. Vengono chiamati strumenti che consentono sia il forward engineering che il reverse engineering bifacciale (andata e ritorno).

Alcuni strumenti utilizzano il codice sorgente come repository e i diagrammi lo utilizzano per la rappresentazione grafica. Tali strumenti sono più strettamente correlati alla programmazione e spesso sono integrati direttamente negli strumenti di modifica del codice sorgente.

Il confine tra modelli e schizzi è piuttosto labile, ma le differenze sono che gli schizzi sono deliberatamente mantenuti incompleti, enfatizzando informazioni importanti, mentre i modelli mirano alla completezza, spesso con l'obiettivo di ridurre la programmazione ad azioni semplici e in qualche modo meccaniche. Cioè, gli schizzi possono essere definiti come elementi di prova e i modelli come definitivi.

Più a lungo si lavora con UML e la programmazione diventa più meccanica, più evidente diventa la necessità di passare alla creazione automatizzata di programmi. In effetti, molti strumenti CASE generano in un modo o nell'altro codice che consente di automatizzare la costruzione di una parte significativa del sistema. Alla fine raggiungerai un punto in cui potrai descrivere l'intero sistema utilizzando UML e sarai in modalità UML. come linguaggio di programmazione . In un ambiente di questo tipo, gli sviluppatori disegnano diagrammi che vengono compilati direttamente nel codice eseguibile e UML diventa il codice sorgente. Ovviamente, una simile applicazione di UML richiede strumenti particolarmente sofisticati. (Inoltre, le notazioni di forward e reverse engineering perdono significato poiché UML e il codice sorgente diventano la stessa cosa.)

Una delle questioni interessanti riguardanti UML come linguaggio di programmazione è la questione della modellazione della logica comportamentale. UML 2 offre tre modi per modellare il comportamento: diagrammi di interazione, diagrammi di stato e diagrammi di attività. Tutti hanno i loro sostenitori nel campo della programmazione.

Un'altra visione dell'UML da parte degli sviluppatori si colloca a metà strada tra il suo utilizzo per la modellazione concettuale e il suo utilizzo per la modellazione del software. La maggior parte degli sviluppatori utilizza UML per modellare il software. CON punto di vista del software Gli elementi UML si associano quasi direttamente agli elementi del sistema software. Come vedremo più avanti, mappare non significa seguire istruzioni, ma quando utilizziamo UML parliamo di elementi software.

CON punto di vista concettuale UML rappresenta una descrizione dei concetti di dominio. Qui non stiamo parlando tanto di elementi software quanto di creare un vocabolario per discutere di un argomento specifico.

Non esistono regole rigide per la scelta di un punto di vista. Poiché il problema può essere visto da diverse angolazioni, ci sono diversi modi per applicarlo. Alcuni strumenti convertono automaticamente il codice sorgente in diagrammi, trattando UML come una forma alternativa di codice sorgente. Questa è in gran parte una prospettiva programmatica. Se i diagrammi UML vengono utilizzati per testare e comprendere i diversi significati dei termini “pool di risorse” con un gruppo di contabili, allora dovrebbe essere adottata una visione concettuale molto più ravvicinata.

Una conseguenza dei diversi usi di UML è che si discute molto sul significato dei diagrammi UML e su come si relazionano con il resto del mondo. Ciò influisce soprattutto sulla relazione tra UML e codice sorgente. Alcuni sviluppatori ritengono che UML dovrebbe essere utilizzato per creare un modello indipendente dal linguaggio di programmazione utilizzato per implementare il progetto. Altri sono convinti che il modello indipendente dalla lingua sia un ossimoro.

Un'altra divergenza di opinioni riguarda la questione della natura dell'UML. Penso che la maggior parte degli utenti UML, in particolare gli sketcher, vedano l'essenza di UML nei suoi diagrammi. Tuttavia, gli autori di UML considerano i diagrammi secondari e il metamodello UML è considerato primario. I diagrammi sono solo una rappresentazione del metamodello. Questo punto di vista ha senso anche per gli sviluppatori che utilizzano UML in modalità progettazione e in modalità linguaggio di programmazione.

Riepilogo: Sono state identificate 3 modalità di utilizzo di UML.

1 - modalità schizzo. Viene redatto uno schizzo del codice futuro (sarà poi necessario scrivere il codice in base al modello) o di quello esistente (per poterlo comprendere meglio). L’obiettivo è un rapido scambio di informazioni. Caratteristica: selettività. La completezza non è importante, è importante il processo di scambio stesso.

2 - modalità di progettazione. L'obiettivo è la completezza. Viene redatto un modello dettagliato, che verrà poi realizzato (e il programmatore non deve pensare molto alla realizzazione, il suo lavoro si riduce a semplici azioni meccaniche). Puoi modellare il tutto o solo una parte.

3 - modalità linguaggio di programmazione. I diagrammi grafici vengono compilati in codice, UML diventa il codice sorgente.

Risposta degli anni precedenti (Den)

Lingua Linguaggio di modellazione unificato (UML) può essere considerato il risultato di un'evoluzione piuttosto lunga e non ancora completata delle metodologie di modellazione e progettazione.

Questa unificazione perseguiva tre obiettivi principali:

· modellazione del sistema, dal concetto al modulo eseguibile, utilizzando tecniche orientate agli oggetti;

· risolvere problemi di scalabilità in sistemi complessi;

· creazione di un linguaggio di modellazione utilizzato sia dagli esseri umani che dai computer.

A cosa serve UML?

UML è innanzitutto un linguaggio e, come qualsiasi strumento linguistico, fornisce un vocabolario e regole per combinare le parole in quel vocabolario. Qui il vocabolario e le regole si concentrano sulle rappresentazioni concettuali e fisiche del sistema. Il linguaggio determina come creare e leggere il modello, ma non fornisce alcuna indicazione sul tipo di modello di sistema da creare: questo va oltre l'ambito di UML ed è l'ambito del processo di sviluppo del software.

UML è un linguaggio di visualizzazione. La scrittura di modelli in UML ha un semplice obiettivo: facilitare il processo di trasferimento delle informazioni sul sistema. Ogni simbolo UML ha una semantica rigorosamente definita, che consente di evitare errori di interpretazione.

UML è un linguaggio di specifiche e definizioni precise. In questo senso, modellare UML significa costruire modelli accurati, inequivocabili e completi.

UML è un linguaggio di documentazione.

Diagrammi UML

La visualizzazione della progettazione del sistema da vari punti di vista in UML viene implementata tramite diagrammi - proiezioni del sistema. Un diagramma è una rappresentazione grafica di un insieme di elementi, rappresentato come un grafico connesso con vertici (entità) e bordi (relazioni).

Di seguito sono riportate le definizioni dei grafici:

· Diagramma delle classi- un diagramma strutturale che mostra molte classi, interfacce, collaborazioni e relazioni tra loro;

· Diagramma degli oggetti- un diagramma strutturale che mostra molti oggetti e le relazioni tra loro. Può essere considerato un caso speciale di diagramma di classi. Non è necessario che gli strumenti di modellazione supportino un formato separato per i diagrammi delle caratteristiche. Rappresentano oggetti, quindi un diagramma di classi che non ha classi, ma ha oggetti che appartengono ad esse, può essere considerato un diagramma di oggetti;

· Diagramma dei casi d'uso- un diagramma di comportamento che mostra molti precedenti e attori, nonché le relazioni tra loro;

· Diagramma di interazione:

o Diagramma di sequenza- un diagramma di comportamento che mostra l'interazione ed evidenzia la sequenza temporale degli eventi;

o Diagramma di collaborazione- un diagramma di comportamento che mostra l'interazione ed enfatizza l'organizzazione strutturale degli oggetti che inviano e ricevono messaggi;

· Diagramma del diagramma di stato- un diagramma di comportamento che mostra la macchina ed evidenzia il comportamento degli oggetti in termini di ordine in cui vengono ricevuti gli eventi;

· Diagramma delle attività- un diagramma di comportamento che mostra la macchina ed evidenzia le transizioni del flusso di controllo da un'attività all'altra;

· Schema dei componenti- un diagramma che mostra l'organizzazione di un determinato insieme di componenti e le dipendenze tra loro - si riferisce al tipo statistico del sistema;

· diagramma della topologia del sistema (diagramma di distribuzione)- un diagramma strutturale che mostra i nodi e le relazioni tra loro.

Risposta degli anni precedenti (Madina)

opzione 1

Metodologia di progettazione degli oggetti in UML (diagrammi UML)

Unified Modeling Language (UML) è un linguaggio per specificare, visualizzare, costruire e documentare, basato su un approccio orientato agli oggetti, diversi tipi di sistemi: software, hardware, software-hardware, misti, che includono esplicitamente attività umane, ecc.

Il linguaggio UML viene utilizzato tra l'altro per progettare database relazionali. A questo scopo viene utilizzata una piccola parte del linguaggio (diagrammi di classe), e anche in questo caso non completamente. Dal punto di vista della progettazione di database relazionali, le capacità del modello non sono troppo diverse da quelle dei diagrammi ER

Diagramma delle classi nella terminologia UML, viene chiamato un diagramma che mostra un insieme di classi (e alcune altre entità) che non sono esplicitamente correlate alla progettazione del database), nonché le relazioni tra queste classi. I vincoli possono essere specificati in modo informale in linguaggio naturale o formulati in OCL (Object Constraints Language).

La classe viene chiamata una descrizione denominata di una raccolta di oggetti con attributi, operazioni, relazioni e semantica comuni. Graficamente la classe è rappresentata come un rettangolo. Nome (stringa di testo) utilizzato per identificare la classe.

Attributo di classeè una proprietà denominata di una classe che descrive l'insieme di valori che possono assumere le istanze di quella proprietà. Una classe può avere un numero qualsiasi di attributi (in particolare, non può avere alcun attributo).

Operazione di classeè un servizio denominato che può essere richiesto da qualsiasi oggetto di questa classe. Un'operazione è un'astrazione di ciò che può essere fatto con un oggetto. Una classe può contenere un numero qualsiasi di operazioni (in particolare, non può contenere alcuna operazione). L'insieme delle operazioni di una classe è comune a tutti gli oggetti di questa classe.

Un diagramma di classi può coinvolgere tre diverse categorie di relazioni: dipendenza, generalizzazione e associazione.

Dipendenza chiamato accoppiamento dell'applicazione quando una modifica nelle specifiche di una classe può influenzare il comportamento di un'altra classe che utilizza la prima classe. Se cambia l'interfaccia della seconda classe, ciò influenza il comportamento degli oggetti della prima classe. Una dipendenza viene visualizzata come una linea tratteggiata con una freccia che punta verso la classe in cui esiste la dipendenza.

Generalizzazione della connessione si chiama connessione tra un'entità comune chiamata superclasse, o genitore, e una versione più specializzata di questa entità chiamata sottoclasse o discendente. Le generalizzazioni sono talvolta chiamate connessioni "è un", il che significa che la classe discendente è un caso speciale della classe antenata. Una classe discendente eredita tutti gli attributi e le operazioni della classe antenata, ma in essa possono essere definiti attributi e operazioni aggiuntivi.

L'ereditarietà singola (dove ciascuna sottoclasse ha solo una superclasse) è sufficiente nella maggior parte dei casi in cui viene utilizzata la relazione generica. Tuttavia UML consente anche l'ereditarietà multipla, quando una sottoclasse è definita sulla base di più superclassi.

In questo diagramma le classi Alunno E Ricercatore derivato dalla stessa superclasse Uomo Dall'Università. Alla classe Alunno fare riferimento a quegli oggetti della classe Uomo Dall'Università, che corrispondono agli studenti e alla classe Ricercatore- oggetti di classe Uomo Dall'Università, corrispondente ai ricercatori. Accade spesso che molti studenti inizino già a partecipare a progetti di ricerca durante i loro anni da studente, quindi potrebbero esserci due oggetti di classe Alunno E Ricercatore, che corrispondono a un oggetto della classe Uomo Dall'Università. Quindi, tra gli oggetti della classe Alunno possono essere ricercatori e alcuni ricercatori possono essere studenti. Quindi possiamo definire la classe StudenteRicercatore attraverso l'ereditarietà multipla dalle superclassi Alunno E Ricercatore. Oggetto di classe StudenteRicercatore ha tutte le proprietà e le operazioni delle classi Alunno E Ricercatore e può essere utilizzato ovunque sia possibile utilizzare oggetti di queste classi. Quindi il polimorfismo di inclusione continua a funzionare. Tuttavia, ciò comporta una serie di problemi. Ad esempio, quando si creano sottoclassi Alunno E Ricercatore entrambi possono avere un attributo definito Indirizzo_IP del computer. Per oggetti di classe Alunno i valori di questo attributo saranno l'indirizzo IP del computer della classe terminale e per gli oggetti della classe Ricercatore- Indirizzo IP del computer del laboratorio di ricerca. Inoltre, per un oggetto di classe StudenteRicercatore Entrambi gli attributi con lo stesso nome possono essere significativi (uno studente ricercatore può avere sia l'indirizzo IP di un computer di classe terminale sia l'indirizzo IP di un computer di un laboratorio di ricerca). In pratica viene utilizzata una delle seguenti soluzioni:

• vietare la formazione di una sottoclasse StudenteRicercatore finché l'attributo non viene rinominato in una delle superclassi Indirizzo_IP del computer;
• eredita questa proprietà solo da una delle superclassi, in modo che, ad esempio, l'attributo value Indirizzo_IP del computer per gli oggetti di classe StudenteRicercatore sarà sempre l'indirizzo IP del computer del laboratorio di ricerca;
• Eredita entrambe le proprietà in una sottoclasse, ma rinomina automaticamente entrambi gli attributi per chiarirne il significato; nominarli, ad esempio, Indirizzo_IP del computer dello studente E Indirizzo_IP del computer del ricercatore.

Ognuna di queste soluzioni presenta degli svantaggi, quindi quando si utilizza UML per progettare database relazionali, è necessario prestare molta attenzione quando si utilizza l'ereditarietà delle classi in generale e cercare di evitare l'ereditarietà multipla.

Associazione chiamata relazione strutturale, che mostra che gli oggetti di una classe sono in qualche modo correlati agli oggetti di un'altra o della stessa classe. È consentito che entrambe le estremità dell'associazione appartengano alla stessa classe. Un'associazione può coinvolgere due classi e quindi si chiama binaria. È possibile creare associazioni che collegano n classi contemporaneamente (si chiamano associazioni n-arie). 1) Graficamente un'associazione è rappresentata come una linea che collega una classe a se stessa o ad altre classi.

Ci sono quattro importanti concetti aggiuntivi associati al concetto di associazione: nome, ruolo, molteplicità e aggregazione. Ad un'associazione può essere assegnato un nome che caratterizza la natura della relazione. Un altro modo per nominare un'associazione è indicare il ruolo di ciascuna classe che partecipa all'associazione. Il ruolo della classe, come il nome della fine della connessione nel modello ER, è specificato dal nome posto sotto la linea di associazione più vicina alla classe data.

In generale, ad un'associazione può essere assegnato sia il proprio nome che i nomi dei ruoli della classe. Questo perché una classe può svolgere lo stesso ruolo in associazioni diverse, quindi in generale una coppia di nomi di ruolo di classe non identifica un'associazione. Nei casi semplici in cui è definita una sola associazione tra due classi, è possibile non associare ad essa alcun nome aggiuntivo.

Molteplicità Il ruolo di un'associazione è una caratteristica che indica quanti oggetti di una classe con un determinato ruolo possono o devono partecipare a ciascuna istanza dell'associazione.

Il modo più comune per specificare la molteplicità di un ruolo di associazione è specificare un numero o un intervallo specifico. Un "1" indica che ogni oggetto classe con un determinato ruolo deve partecipare a qualche istanza di questa associazione e solo un oggetto classe con un determinato ruolo può partecipare a ciascuna istanza dell'associazione. Specificare l'intervallo "0..1" indica che non tutti gli oggetti di una classe con un determinato ruolo devono partecipare a qualsiasi istanza di una determinata associazione, ma solo un oggetto può partecipare a ciascuna istanza di un'associazione. Allo stesso modo, specificando l'intervallo "1..*" indica che tutti gli oggetti di una classe con un dato ruolo devono partecipare a qualche istanza di questa associazione, e almeno un oggetto deve partecipare a ciascuna istanza dell'associazione (non viene specificato alcun limite superiore ). Nei casi più complessi di determinazione della molteplicità, è possibile utilizzare elenchi di intervalli.

La consueta associazione tra due classi caratterizza il rapporto tra entità uguali: entrambe le classi si trovano sullo stesso livello concettuale. Ma a volte un diagramma di classe deve riflettere il fatto che l'associazione tra due classi ha una speciale forma parte-intero. In questo caso la classe "tutto" ha un livello concettuale più alto della classe "parte". Un'associazione di questo tipo si chiama aggregato.

I computer devono essere installati in ciascuna classe di terminali. Quindi classe Computerè "parte" della classe TerminalClass. Ruolo della classe Computerè facoltativo, poiché in linea di principio le classi terminali possono esistere senza computer. Inoltre, sebbene le classi terminali non dotate di computer non svolgano la loro funzione, classificano gli oggetti TerminalClass E Computer esistere indipendentemente.

Ci sono casi in cui la connessione tra la “parte” e il “tutto” è così forte che la distruzione del “tutto” porta alla distruzione di tutte le sue “parti”. Vengono chiamate le associazioni aggregate con questa proprietà composito, o semplicemente composizioni.

Qualsiasi facoltà fa parte di un'università e la liquidazione di un'università porta alla liquidazione di tutte le facoltà esistenti in essa, sebbene durante l'esistenza dell'università le singole facoltà possano essere liquidate e create.

I diagrammi di classe possono specificare vincoli di integrità che devono essere supportati nel database progettato. UML consente due modi per definire i vincoli: in linguaggio naturale e in OCL (Object Constraints Language).

Dal punto di vista della definizione dei vincoli di integrità del database, i mezzi per definire le invarianti di classe sono più importanti.

Sotto invariante La classe in OCL è intesa come una condizione che tutti gli oggetti di una determinata classe devono soddisfare. Più precisamente, un invariante di classe è un'espressione logica, la cui valutazione deve rivelarsi vera quando viene creato un oggetto di una determinata classe e mantenere un valore vero per tutta l'esistenza di questo oggetto. Quando si definisce un invariante, è necessario specificare il nome della classe e un'espressione che definisca l'invariante della classe specificata. Sintatticamente assomiglia a questo:

Di seguito sono riportati esempi di invarianti per specificare i vincoli in OCL.

1. Esprimere in OCL il vincolo secondo il quale i dipendenti di età superiore ai 30 anni devono lavorare in reparti con numeri superiori a 5

2. Definire il vincolo secondo cui ogni dipartimento deve avere un manager e che ogni dipartimento non deve essere fondato prima della società corrispondente

3. La condizione della quarta invariante limita il numero massimo possibile di dipendenti dell'azienda a 1000

opzione 2

1. Modello RUP. Schemi fondamentali del modello RUP.

Rational Unified Process (RUP) è una delle metodologie di sviluppo software a spirale. La metodologia è supportata da Rational Software e il prodotto viene aggiornato circa due volte l'anno. L'UML (Unified Modeling Language) viene utilizzato come linguaggio di modellazione nella base di conoscenza generale.

Lo sviluppo iterativo del software in RUP prevede la divisione di un progetto in diversi piccoli progetti che vengono eseguiti in sequenza e ogni iterazione di sviluppo è chiaramente definita da una serie di obiettivi che devono essere raggiunti alla fine dell'iterazione. L'iterazione finale presuppone che l'insieme degli obiettivi dell'iterazione debba corrispondere esattamente all'insieme degli obiettivi specificati dal cliente del prodotto, ovvero che tutti i requisiti debbano essere soddisfatti. RUP fornisce un approccio strutturato allo sviluppo iterativo del software, suddividendo il processo in quattro fasi fondamentali nel tempo: avvio, elaborazione, costruzione e transizione. Il RUP raccomanda di seguire sei pratiche per sviluppare con successo un progetto:

Sviluppo iterativo;

Gestione dei requisiti;

Utilizzo di architetture modulari;

Modellazione visiva;

Controllo qualità;

Tenere traccia delle modifiche.

Vengono chiamate rappresentazioni grafiche dei modelli di sistema in UML diagrammi. In termini di linguaggio UML, sono definiti i seguenti tipi:

· caso d'uso o diagramma del caso d'uso(diagramma dei casi d'uso)

· diagramma di classe(diagramma delle classi)

· grafici di comportamento(diagrammi comportamentali)

· diagramma di stato(diagramma dello stato)

· diagramma di attività(diagramma delle attività)

· diagrammi di interazione(diagrammi di interazione)

· diagramma di sequenza(diagramma di sequenza)

· diagramma di cooperazione(diagramma di collaborazione)

· diagrammi di implementazione(schemi di implementazione)

· diagramma dei componenti(schema dei componenti)

· diagramma di distribuzione(diagramma di distribuzione)

Ciascuno di questi diagrammi specifica una visione diversa del modello del sistema. Allo stesso tempo, il diagramma dei casi d’uso rappresenta un modello concettuale del sistema, che è il punto di partenza per la costruzione di tutti gli altri diagrammi. Un diagramma di classe è un modello logico che riflette gli aspetti statici della progettazione strutturale di un sistema, mentre i diagrammi di comportamento, che sono anche tipi di modello logico, riflettono gli aspetti dinamici del suo funzionamento. I diagrammi di implementazione servono a rappresentare i componenti di un sistema e fanno riferimento al suo modello fisico.

Dei diagrammi sopra elencati, alcuni servono a designare due o più sottospecie. I seguenti diagrammi vengono utilizzati come rappresentazioni indipendenti: casi d'uso, classi, stati, attività, sequenze, cooperazione, componenti E distribuzione.

Per i diagrammi UML esistono tre tipi di simboli visivi importanti in termini di informazioni che contengono:

· comunicazioni, che sono rappresentati da diverse linee sul piano;

· testo, contenuto entro i confini delle singole forme geometriche;

· simboli grafici, raffigurato vicino agli elementi visivi dei diagrammi.

· ciascun diagramma deve essere una rappresentazione completa di qualche frammento dell'area tematica modellata;

· le entità del modello presentate nel diagramma devono essere dello stesso livello concettuale;

· tutte le informazioni sulle entità devono essere presentate chiaramente nel diagramma;

· i diagrammi non devono contenere informazioni contrastanti;

· i diagrammi non dovrebbero essere sovraccaricati di informazioni testuali;

· ogni schema deve essere autosufficiente per la corretta interpretazione di tutti i suoi elementi;

· il numero di tipi di diagrammi richiesti per descrivere un sistema specifico non è strettamente fisso ed è determinato dallo sviluppatore;

I modelli di sistema dovrebbero contenere solo gli elementi definiti

22. Progettazione di circuiti integrati [J]

La risposta pronta di Tony

Le risposte di Denis Kovalevich sono state aggiornate

Fase di implementazione

Uno dei motivi principali delle implementazioni infruttuose è lo scarso sviluppo del progetto IS nella fase di consulenza gestionale. Di conseguenza, il sistema informativo risulta non sufficientemente integrato nel complessivo sistema di gestione aziendale.

· mancanza di sostegno da parte del personale chiave, soprattutto quando è necessario dedicare tempo ed energie sufficienti alle fasi critiche;

· piani troppo ambiziosi invece di un approccio saggio e graduale;

· incapacità di ottenere consulenza sufficiente da professionisti con esperienza effettiva nell'uso di sistemi simili in attività simili.

Fase operativa

o uso quotidiano;

Disposizione

Risposta degli anni precedenti (Madina)

Implementazione.

2.1. Redazione di progetti tecnici (TP).

i consulenti dell'appaltatore e gli specialisti informatici del cliente compongono il TP;

Il cliente approva il TP.

L'ambito del lavoro, i tempi e i costi sono specificati.

I materiali TP vengono utilizzati durante la pianificazione e la documentazione del lavoro.

Composizione del TP:

struttura dei dati memorizzati;

algoritmi;

risorse di sistema utilizzate, loro struttura e connessioni;

interfaccia utente.

2.2. Pianificazione del lavoro.

In conformità con le normative approvate

i project manager dell'appaltatore e del cliente elaborano i programmi di lavoro (WP);

il cliente e l'appaltatore approvano la RP.

Vengono elaborati piani individuali per i membri del gruppo di lavoro.

Composizione dell'RP:

elenco dei lavori: configurazione, test, accettazione (l'elenco dei lavori può includere specifiche tecniche e specifiche tecniche);

tempo di consegna;

responsabile di ogni punto del RP.

2.3. Compilazione di libri di consultazione di base.

Caratteristiche del palco:

può richiedere da 1 a 18 mesi;

richiede la centralizzazione dell'input delle informazioni;

è una condizione necessaria per il funzionamento del sistema.

Metodi di implementazione:

conversione dei dati;

inserimento manuale dei dati da parte degli utenti (operatori).

2.4. Impostazione, test, accettazione.

Caratteristiche del palco:

il più laborioso e responsabile;

dipende in modo significativo dalla preparazione preliminare (normative, specifiche tecniche, specifiche tecniche, RP);

richiede una rigida disciplina sia da parte dell'esecutore che da parte del cliente;

accompagnato dalla comparsa di compiti aggiuntivi da parte del cliente;

richiede flessibilità da parte del cliente e dell'appaltatore per superare le situazioni di conflitto.

2.5. Operazione di prova.

Caratteristiche del palco:

richiede una risposta pronta e affidabile da parte dell'esecutore;

può richiedere uno sforzo significativo da parte del cliente (doppio lavoro);

ha una durata significativa (1-3 mesi);

accompagnato dalla formazione di un elenco finale di commenti (suggerimenti), pianificazione ed esecuzione del lavoro finale su configurazione, test e accettazione.

2.6. Documentazione.

predisposizione di istruzioni per gli utenti;

elaborazione di regolamenti per l'interazione dei servizi all'interno del sistema;

finalizzazione della documentazione tecnica;

formazione di altri documenti (pre-concordati).

2.7. Completamento del progetto.

chiusura giuridica dei rapporti contrattuali;

liquidazioni finanziarie finali;

prendere decisioni su un'ulteriore cooperazione: concludere accordi per il supporto tecnico e il supporto post-garanzia, implementare nuovi progetti.

Riciclo della proprietà intellettuale– effettuato con il pulsante CANCELLA.

Risposta degli anni precedenti (Den)

Fase di implementazione

La fase di sviluppo e implementazione è solitamente sempre completata per intero. Non è ostacolato dallo scarso sviluppo della tecnologia, dalla mancanza di competenza del personale o degli utenti o dalla mancanza di buoni consulenti.

Se in questa fase sorgono problemi, essi sono associati ai seguenti tre motivi principali:

mancanza di supporto da parte del personale chiave, soprattutto quando è necessario dedicare tempo ed energie sufficienti alle fasi critiche;

piani eccessivamente ambiziosi invece di un approccio saggio e graduale;

incapacità di ottenere consigli sufficienti da professionisti con esperienza effettiva nell'utilizzo di sistemi simili in attività simili.

Fase operativa

· Messa in funzione del sistema informativo

o messa in servizio dell'attrezzatura tecnica durante il funzionamento di prova;

o messa in prova del software;

o formazione e certificazione del personale;

o esecuzione del funzionamento di prova dei componenti e del sistema nel suo insieme;

o messa in servizio e firma dei certificati di accettazione dei lavori.

· Funzionamento del sistema informativo

o uso quotidiano;

o supporto del software, dell'hardware e dell'intero progetto.

Fase di supporto (manutenzione).

I servizi di supporto tecnico svolgono un ruolo molto significativo nella vita di qualsiasi sistema informativo aziendale. La presenza di un servizio tecnico qualificato nella fase di funzionamento di un sistema informativo è una condizione necessaria per risolvere i compiti ad esso assegnati, e gli errori del personale addetto alla manutenzione possono portare a perdite finanziarie evidenti o nascoste paragonabili al costo del sistema informativo stesso.

Le principali azioni preliminari in preparazione all'organizzazione della manutenzione di un sistema informativo sono:

· identificare i componenti più critici del sistema e determinare la criticità dei tempi di inattività degli stessi (questo consentirà di identificare i componenti più critici del sistema informativo e di ottimizzare l'allocazione delle risorse per la manutenzione);

· identificazione dei compiti di manutenzione e loro divisione in interni, risolti dal reparto di assistenza, ed esterni, risolti da organizzazioni di servizi specializzate (viene così effettuata una chiara definizione della gamma di funzioni svolte e divisione delle responsabilità);

· analisi delle risorse interne ed esterne disponibili necessarie per organizzare la manutenzione nell'ambito dei compiti descritti e divisione delle competenze (principali criteri di analisi: disponibilità di una garanzia sulle attrezzature, stato del fondo di riparazione, qualifiche del personale);

· predisposizione di un piano di organizzazione della manutenzione, nel quale occorre determinare le fasi degli interventi da eseguire, i tempi della loro esecuzione, i costi delle fasi e la responsabilità degli esecutori.

Fornire una manutenzione tecnica di alta qualità di un sistema informativo richiede il coinvolgimento di specialisti altamente qualificati in grado di risolvere non solo i compiti amministrativi quotidiani, ma anche di ripristinare rapidamente il sistema in caso di guasti.

Disposizione

Liquidazione di un prodotto con conversione dei suoi componenti in materie prime seconde (nel rispetto dei requisiti ambientali), accompagnata dall'esclusione di tutte le informazioni relative all'articolo liquidato dal sistema informativo informativo.

Questo argomento è trattato in modo molto dettagliato su http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 e su http://www.rus-lib.ru/book/38/men/21 /2.3.html

23. Progettazione di circuiti integrati [J]

Informazioni correlate.

una definizione simile a quella riportata di seguito.

Lingua- un sistema di segnaletica che serve:

• un mezzo di comunicazione umana e di attività mentale;
• un modo di esprimere l'autoconsapevolezza di una persona;
• un mezzo per archiviare e trasmettere informazioni.

La lingua comprende un insieme di segni (vocabolario) e regole per il loro uso e interpretazione (grammatica).

A questa definizione piuttosto esaustiva bisogna aggiungere che le lingue possono essere naturali e artificiali, formali e informali. UML è un linguaggio formale e artificiale, anche se, come vedremo in seguito, questa etichetta non gli si addice del tutto. È artificiale perché ha degli autori, di cui parleremo più volte in futuro (allo stesso tempo, lo sviluppo di UML continua continuamente, il che lo pone alla pari dei linguaggi naturali). Può dirsi formale perché esistono delle regole per il suo utilizzo (la descrizione UML contiene però anche elementi chiaramente informali, come vedremo ancora in seguito). Ancora una sfumatura: UML è un linguaggio grafico, il che confonde un po' la situazione!

Quando si descrive un linguaggio artificiale formale, che abbiamo già visto negli esempi di descrizione dei linguaggi di programmazione, di norma, tali elementi sono descritti come:

1. sintassi, cioè determinare le regole per costruire i costrutti linguistici;
2. semantica, cioè la definizione di regole secondo le quali le strutture linguistiche acquisiscono significato semantico;
3. pragmatica, cioè determinare le regole per l'utilizzo dei costrutti linguistici per raggiungere gli obiettivi di cui abbiamo bisogno.

Inoltre, più o meno nello stesso periodo (primi anni ’80), iniziò “l’era orientata agli oggetti”. Tutto è iniziato con l'avvento della famiglia di linguaggi di programmazione SmallTalk, che ha applicato alcuni dei concetti del linguaggio Simula-67 utilizzato negli anni '60. L’emergere dell’approccio orientato agli oggetti è dovuto principalmente alla crescente complessità dei problemi. Approccio orientato agli oggetti ha apportato modifiche piuttosto radicali ai principi stessi della creazione e del funzionamento dei programmi, ma, allo stesso tempo, ha permesso di aumentare in modo significativo prestazione il lavoro dei programmatori, per dare uno sguardo diverso ai problemi e ai metodi per risolverli, per rendere i programmi più compatti e facilmente estensibili. Di conseguenza, i linguaggi originariamente orientati all'approccio tradizionale alla programmazione hanno ricevuto una serie di estensioni orientate agli oggetti. Una delle prime, a metà degli anni 80, fu Apple con il suo progetto Object Pascal. Oltretutto, approccio orientato agli oggetti ha generato una potente ondata di tecnologie software completamente nuove, i cui apici erano piattaforme generalmente riconosciute come Microsoft. NET Framework e Sun Java.

Ma la cosa più importante è che l'emergere dell'OOP richiedeva uno strumento utile per la modellazione, una notazione unificata per descrivere sistemi software complessi. E così i “tre amigos”, tre grandi specialisti, tre autori dei metodi più apprezzati, hanno deciso di unire i loro sviluppi. Nel 1991, ciascuno dei “tre amigos” iniziò scrivendo un libro in cui esponeva il proprio metodo OOAP. Ogni metodologia era

UML è un linguaggio di modellazione grafica unificato per descrivere, visualizzare, progettare e documentare sistemi OO. UML è progettato per supportare il processo di modellazione del software basato sull'approccio OO, organizzare la relazione tra concetti concettuali e di programma e riflettere i problemi di scalabilità di sistemi complessi. I modelli UML vengono utilizzati in tutte le fasi del ciclo di vita del software, dall'analisi aziendale alla manutenzione del sistema. Diverse organizzazioni possono utilizzare UML come ritengono opportuno, a seconda delle aree problematiche e delle tecnologie utilizzate.

Una breve storia di UML

Verso la metà degli anni '90, vari autori avevano proposto diverse dozzine di metodi di modellazione OO, ciascuno dei quali utilizzava la propria notazione grafica. Allo stesso tempo, ognuno di questi metodi aveva i suoi punti di forza, ma non consentiva di costruire un modello sufficientemente completo del PS, mostrandolo “da tutti i lati”, cioè tutte le proiezioni necessarie (vedi articolo 1). Inoltre, la mancanza di uno standard di modellazione OO ha reso difficile per gli sviluppatori scegliere il metodo più adatto, impedendo l’adozione diffusa dell’approccio OO allo sviluppo software.

Su richiesta dell'Object Management Group (OMG), l'organizzazione responsabile dell'adozione di standard nel campo delle tecnologie degli oggetti e dei database, il problema urgente dell'unificazione e della standardizzazione è stato risolto dagli autori dei tre metodi OO più popolari - G Butch, D. Rambo e A. Jacobson, che unirono gli sforzi crearono la versione UML 1.1, approvata da OMG nel 1997 come standard.

UML è un linguaggio

Qualsiasi lingua è costituita da un vocabolario e da regole per combinare le parole per creare costruzioni significative. Questo è, in particolare, il modo in cui sono strutturati i linguaggi di programmazione, compreso UML. La sua caratteristica distintiva è che il dizionario della lingua è formato da elementi grafici. Ogni simbolo grafico ha una semantica specifica ad esso associata, quindi un modello creato da uno sviluppatore può essere chiaramente compreso da un altro, nonché da uno strumento software che interpreta UML. Da qui, in particolare, ne consegue che un modello software presentato in UML può essere automaticamente tradotto in un linguaggio di programmazione OO (come Java, C++, VisualBasic), cioè se esiste un buon strumento di modellazione visiva che supporti UML, avendo costruito il modello, riceveremo anche un codice di programma di esempio corrispondente a questo modello.

Va sottolineato che UML è un linguaggio, non un metodo. Spiega da quali elementi creare modelli e come leggerli, ma non dice nulla su quali modelli dovrebbero essere sviluppati e in quali casi. Per creare un metodo basato su UML è necessario integrarlo con una descrizione del processo di sviluppo del software. Un esempio di tale processo è il Rational Unified Process, di cui parleremo negli articoli successivi.

Dizionario UML

Il modello è rappresentato sotto forma di entità e relazioni tra loro, mostrate nei diagrammi.

Entità sono le astrazioni che costituiscono gli elementi principali dei modelli. Esistono quattro tipi di entità: strutturali (classe, interfaccia, componente, caso d'uso, collaborazione, nodo), comportamentali (interazione, stato), raggruppamento (pacchetti) e annotazione (commenti). Ogni tipo di entità ha la propria rappresentazione grafica. Le entità verranno discusse in dettaglio durante lo studio dei diagrammi.

Relazione mostrano varie connessioni tra entità. UML definisce i seguenti tipi di relazione:

• Dipendenza mostra una tale connessione tra due entità quando un cambiamento in una di esse - indipendente - può influenzare la semantica dell'altra - dipendente. La dipendenza è rappresentata da una freccia tratteggiata diretta dall'entità dipendente all'entità indipendente.
• Associazioneè una relazione strutturale che mostra che gli oggetti di un'entità sono correlati agli oggetti di un'altra. Graficamente un'associazione viene rappresentata come una linea che collega le entità associate. Le associazioni servono per navigare tra gli oggetti. Ad esempio, l'associazione tra le classi “Ordine” e “Prodotto” può essere utilizzata per trovare da un lato tutti i prodotti specificati in un ordine specifico o dall'altro tutti gli ordini che contengono questo prodotto. È chiaro che i programmi corrispondenti devono implementare un meccanismo che fornisca tale navigazione. Se è richiesta la navigazione in una sola direzione, ciò viene indicato da una freccia alla fine dell'associazione. Un caso particolare di associazione è l'aggregazione, una relazione nella forma “intero” – “parte”. Graficamente è evidenziato con un diamante all'estremità vicino all'essenza-insieme.
• Generalizzazioneè la relazione tra un'entità madre e un'entità figlio. Essenzialmente, questa relazione riflette la proprietà dell'ereditarietà per classi e oggetti. La generalizzazione viene mostrata come una linea che termina con un triangolo diretto verso l'entità madre. Il figlio eredita la struttura (attributi) e il comportamento (metodi) del genitore, ma allo stesso tempo può avere nuovi elementi strutturali e nuovi metodi. UML consente l'ereditarietà multipla, in cui un'entità è correlata a più di un'entità madre.
• Implementazione– la relazione tra un'entità che definisce una specifica di comportamento (interfaccia) con un'entità che definisce l'implementazione di questo comportamento (classe, componente). Questa relazione viene comunemente utilizzata durante la modellazione dei componenti e verrà descritta in maggior dettaglio negli articoli successivi.

Diagrammi. UML fornisce i seguenti diagrammi:

• Diagrammi che descrivono il comportamento del sistema:
• Diagrammi di stato
• Diagrammi di attività,
• Diagrammi degli oggetti,
• Diagrammi di sequenza,
• Diagrammi di collaborazione;
• Diagrammi che descrivono l'implementazione fisica del sistema:
• Schemi dei componenti;
• Diagrammi di distribuzione.

Vista di controllo del modello. Pacchetti.

Abbiamo già detto che affinché un modello sia ben compreso dagli esseri umani è necessario organizzarlo gerarchicamente, lasciando ad ogni livello della gerarchia un piccolo numero di entità. UML include un mezzo per organizzare una rappresentazione gerarchica di un modello: i pacchetti. Qualsiasi modello è costituito da un insieme di pacchetti che possono contenere classi, casi d'uso e altre entità e diagrammi. Un pacchetto può contenere altri pacchetti, consentendo la creazione di gerarchie. UML non fornisce diagrammi di pacchetto separati, ma potrebbero apparire in altri diagrammi. Il pacchetto è raffigurato come un rettangolo con un segnalibro.

Cosa offre UML.

• descrizione gerarchica di un sistema complesso identificando i pacchetti;
• formalizzazione dei requisiti funzionali del sistema utilizzando l'apparato dei casi d'uso;
• dettagliare i requisiti di sistema costruendo diagrammi di attività e scenari;
• identificare le classi di dati e costruire un modello concettuale di dati sotto forma di diagrammi di classi;
• identificare le classi che descrivono l'interfaccia utente e creare uno schema di navigazione sullo schermo;
• descrizione dei processi di interazione degli oggetti durante l'esecuzione delle funzioni di sistema;
• descrizione del comportamento degli oggetti sotto forma di diagrammi di attività e di stato;
• descrizione dei componenti software e della loro interazione tramite interfacce;
• descrizione dell’architettura fisica del sistema.

E l'ultima cosa...

Nonostante tutta l'attrattiva di UML, sarebbe difficile da utilizzare nella modellazione software reale senza strumenti di modellazione visiva. Tali strumenti consentono di presentare rapidamente diagrammi sullo schermo del display, documentarli, generare modelli di codice di programma in vari linguaggi di programmazione OO e creare schemi di database. La maggior parte di essi include la possibilità di reingegnerizzare i codici dei programmi, ripristinando alcune proiezioni del modello software analizzando automaticamente i codici sorgente dei programmi, il che è molto importante per garantire la conformità tra modello e codici e quando si progettano sistemi che ereditano la funzionalità dei sistemi precedenti.

L'Unified Modeling Language (UML) è uno strumento standard per la creazione di "progetti" di sistemi informativi (IS). Utilizzando UML è possibile visualizzare, specificare, progettare e documentare gli elementi di questi sistemi.

UML è adatto per modellare qualsiasi sistema: dai sistemi informativi su scala aziendale alle applicazioni Web distribuite e persino ai sistemi in tempo reale integrati. È un linguaggio molto espressivo che permette di vedere un sistema da tutti i punti di vista rilevanti per il suo sviluppo e la successiva implementazione. Nonostante l’abbondanza di possibilità espressive, questo linguaggio è di facile comprensione e utilizzo. Il posto migliore per iniziare ad apprendere UML è con il suo modello concettuale, che comprende tre elementi di base: gli elementi costitutivi di base, le regole che definiscono come tali blocchi possono essere combinati e alcuni meccanismi generali del linguaggio.

UML è uno dei componenti del processo di sviluppo dell'IS. Sebbene UML sia indipendente dalla realtà modellata, viene utilizzato al meglio quando il processo di modellazione si basa su considerazioni sui casi d'uso, è iterativo e incrementale e il sistema stesso ha un'architettura ben definita.

UML è un linguaggio per visualizzare, specificare, costruire e documentare elementi di sistemi software. Una lingua è costituita da un dizionario e da regole che permettono di combinare le parole in essa contenute e creare costruzioni dotate di significato. In un linguaggio di modellizzazione, il vocabolario e le regole si concentrano sulla rappresentazione concettuale e fisica del sistema. Un linguaggio di modellazione come UML è uno strumento standard per elaborare "progetti" di IC.

Quando si crea un IS di qualsiasi complessità, viene eseguita la modellazione del sistema futuro, ma in molti casi ciò avviene in modo informale, senza sviluppare alcun documento. Tuttavia, questo approccio è irto di problemi. Innanzitutto, uno scambio di opinioni su un modello concettuale è possibile solo quando tutti i partecipanti alla discussione parlano la stessa lingua. In secondo luogo, è impossibile comprendere alcuni aspetti dei sistemi informativi senza un modello che vada oltre i confini di un linguaggio di programmazione basato su testo. In terzo luogo, se l’autore del codice non ha mai implementato esplicitamente i modelli che intendeva, queste informazioni andranno perse per sempre se cambia lavoro. Nella migliore delle ipotesi, può essere ricreato solo parzialmente in base all'implementazione.

L'uso di UML risolve il terzo problema: un modello esplicito facilita la comunicazione.

Alcune funzionalità del sistema sono meglio modellate testualmente, altre graficamente. In effetti, in tutti i sistemi interessanti ci sono strutture che non possono essere rappresentate utilizzando solo un linguaggio di programmazione. UML è un linguaggio grafico che ci consente di risolvere il secondo dei problemi identificati.

UML è molto più di un semplice insieme di simboli grafici. Dietro ognuno di essi c'è una semantica ben definita. Ciò significa che un modello scritto da uno sviluppatore può essere interpretato in modo inequivocabile da un altro o anche da un programma strumento. Questo risolve il primo dei problemi sopra elencati.

In questo contesto specifica significa costruire modelli accurati, univoci e completi. UML consente di specificare tutte le decisioni significative di analisi, progettazione e implementazione che devono essere prese durante lo sviluppo e l'implementazione di un sistema informativo.

UML è un linguaggio di progettazione visiva e i modelli creati utilizzandolo possono essere tradotti direttamente in vari linguaggi di programmazione IS.

Quando si sviluppa un IS, elementi come:

• requisiti di sistema;
• descrizione dell'architettura;
• progetto;
• fonte;
• piani di progetto;
• test;
• prototipi;
• versioni, ecc.

A seconda della metodologia di sviluppo adottata, alcuni lavori vengono eseguiti in modo più formale di altri. Gli articoli citati non sono semplicemente componenti forniti del progetto; sono necessari per la gestione, per la valutazione dei risultati e anche come mezzo di comunicazione tra i membri del team durante lo sviluppo del sistema e dopo la sua implementazione.

UML risolve il problema di documentare l'architettura del sistema e tutti i suoi dettagli, fornisce un linguaggio per formulare i requisiti di sistema e definire i test e infine fornisce strumenti per il lavoro di modellazione durante le fasi di pianificazione del progetto e di controllo della versione.

Dove viene utilizzato UML

Il linguaggio UML è destinato principalmente allo sviluppo di sistemi informativi. Il suo utilizzo è particolarmente efficace nei seguenti ambiti:

• sistemi informativi su scala aziendale;
• servizi bancari e finanziari;
• telecomunicazioni;
• trasporto;
• industria della difesa, aviazione e astronautica;
• vedere al dettaglio;
• elettronica medica;
• la scienza;
• sistemi Web distribuiti.

L'ambito di UML non è limitato alla modellazione del software. La sua espressività rende possibile modellare, ad esempio, il flusso di documenti nei sistemi legali, la struttura e il funzionamento di un sistema di servizi ai pazienti negli ospedali e progettare hardware.

Modello concettuale UML

Per comprendere UML è necessario comprendere il suo modello concettuale, che comprende tre componenti: gli elementi costitutivi di base del linguaggio, le regole per combinarli e alcuni meccanismi comuni all'intero linguaggio. Avendo padroneggiato questi elementi, sarai in grado di leggere i modelli UML e crearli tu stesso, all'inizio, ovviamente, non molto complessi. Man mano che acquisisci esperienza con la lingua, imparerai a utilizzare le sue capacità più avanzate.

Elementi costitutivi dell'UML

Il vocabolario UML comprende tre tipi di elementi costitutivi:

• essenze;
• relazione;
• diagrammi.

Le entità sono astrazioni che costituiscono gli elementi principali del modello. Le relazioni collegano entità diverse; i diagrammi raggruppano raccolte di entità di interesse.

Esistono quattro tipi di entità in UML:

• strutturale;
• comportamentale;
• raggruppamento;
• annotativo.

Le entità sono i blocchi base orientati agli oggetti del linguaggio. Con il loro aiuto, puoi creare modelli corretti. Esistono sette tipi di entità strutturali:

• Classe
• Interfaccia
• Cooperazione
• Caso d'uso
• Classe attiva
• Componente
• Nodo

Questi sette elementi di base (classi, interfacce, collaborazioni, casi d'uso, classi attive, componenti e nodi) sono le entità strutturali di base che possono essere incluse in un modello UML. Esistono anche varietà di queste entità: attori, segnali, utilità (tipi di classi), processi e thread (tipi di classi attive), applicazioni, documenti, file, librerie, pagine e tabelle (tipi di componenti).

Gli elementi comportamentali sono i componenti dinamici di un modello UML. Questi sono verbi del linguaggio: descrivono il comportamento del modello nel tempo e nello spazio. Esistono solo due tipi principali di entità comportamentali:

• Interazione
• Macchina statale

Questi due elementi di interazione e gli automi sono le principali entità comportamentali incluse nel modello UML. Semanticamente, sono spesso associati a vari elementi strutturali, principalmente classi, collaborazioni e oggetti.

Le entità di raggruppamento sono le parti organizzative di un modello UML. Questi sono i blocchi in cui è possibile scomporre il modello. Esiste una sola entità di raggruppamento primaria, vale a dire sacchetto di plastica.

I pacchetti sono le entità di raggruppamento di base che possono essere utilizzate per organizzare un modello UML. Esistono anche varianti di pacchetti, come framework, modelli e sottosistemi.

Entità di annotazione— parti esplicative del modello UML. Si tratta di commenti volti a fornire ulteriori descrizioni, chiarimenti o commenti su qualsiasi elemento del modello. Esiste un solo tipo base di elemento di annotazione: Nota. Una nota è semplicemente un simbolo per rappresentare commenti o restrizioni associati a un elemento o gruppo di elementi. Graficamente una nota viene rappresentata come un rettangolo con il bordo curvo contenente un commento testuale o grafico.

L'UML definisce quattro tipi di relazioni:

• dipendenza;
• associazione;
• generalizzazione;
• implementazione.

Queste relazioni costituiscono gli elementi costitutivi di connessione di base in UML e vengono utilizzate per creare modelli validi.
I quattro elementi descritti rappresentano i principali tipi di relazioni che possono essere inclusi nei modelli UML. Esistono anche varianti, come Perfezionamento, Traccia, Inclusione ed Estensione (per le dipendenze).

Un diagramma in UML è una rappresentazione grafica di un insieme di elementi, spesso rappresentato come un grafico connesso con vertici (entità) e bordi (relazioni). I diagrammi vengono disegnati per visualizzare un sistema da diverse prospettive. Il diagramma è in un certo senso una delle proiezioni del sistema. Di norma, tranne i casi più banali, i diagrammi forniscono una visione sintetica degli elementi che compongono il sistema. Lo stesso elemento può essere presente in tutti i diagrammi, o solo in alcuni (l'opzione più comune), o non presente in nessuno (molto raro). In teoria, i diagrammi possono contenere qualsiasi combinazione di entità e relazioni. Nella pratica, però, vengono utilizzate un numero relativamente piccolo di combinazioni standard, corrispondenti alle cinque tipologie più comuni che compongono l'architettura del sistema informativo. Pertanto, ci sono nove tipi di diagrammi in UML:

• diagrammi di classe;
• diagrammi di oggetti;
• diagrammi dei casi d'uso;
• diagrammi di sequenza;
• diagrammi di cooperazione;
• diagrammi di stato;
• diagrammi di attività;
• diagrammi dei componenti;
• diagrammi di distribuzione.

Di seguito è riportato un elenco parziale dei diagrammi utilizzati in UML. Gli strumenti ti consentono di generare altri diagrammi, ma i nove elencati sono quelli che vedi più spesso nella pratica.

Regole del linguaggio UML

Gli elementi costitutivi di UML non possono essere combinati arbitrariamente tra loro. Come ogni altro linguaggio, UML è caratterizzato da un insieme di regole che definiscono come dovrebbe apparire un modello ben formattato, cioè semanticamente autoconsistente e in armonia con tutti i modelli ad esso associati.

Il linguaggio UML possiede regole semantiche che permettono di definire in modo corretto ed inequivocabile:

• nomi, che può essere assegnato a entità, relazioni e diagrammi;
• scopo(contesto in cui il nome ha un significato);
• visibilità(quando i nomi sono visibili e possono essere utilizzati da altri elementi);
• integrità(come gli elementi dovrebbero relazionarsi correttamente e coerentemente tra loro);
• prestazione(che significa eseguire o simulare un modello dinamico).

I modelli creati durante lo sviluppo dei sistemi informativi si evolvono nel tempo e possono essere visualizzati in modo diverso dai diversi partecipanti al progetto in momenti diversi. Per questo motivo non vengono creati solo modelli ben progettati, ma anche che:

• contengono elementi nascosti (alcuni elementi non vengono mostrati per semplificarne la percezione);
• incompleto (mancano singoli elementi);
• incoerente (l'integrità del modello non è garantita).

La comparsa di modelli non molto ben progettati è inevitabile durante il processo di sviluppo finché tutti i dettagli del sistema non saranno completamente chiariti. Le regole UML incoraggiano, ma non richiedono, ad affrontare problemi critici di analisi, progettazione e implementazione mentre si lavora sul modello, ottenendo nel tempo un modello ben formulato.

Meccanismi generali UML

La costruzione diventa più semplice ed efficiente se si seguono determinate convenzioni. Seguendo determinati schemi architettonici, puoi progettare un edificio in stile vittoriano o francese. Lo stesso principio vale per UML. Lavorare con questo linguaggio è notevolmente facilitato dall’uso coerente dei meccanismi generali elencati di seguito:

• specifiche (Specifiche);
• aggiunte (Ornamenti);
• divisioni comuni;
• Meccanismi di estensibilità.

Architettura

Per visualizzare, specificare, costruire e documentare i sistemi informativi è necessario considerarli da diversi punti di vista. Tutti coloro che sono coinvolti in un progetto (utenti finali, analisti, sviluppatori, integratori di sistema, tester, redattori tecnici e project manager) hanno i propri interessi e ognuno vede la costruzione del sistema in modo diverso in diversi momenti della sua vita. L’architettura del sistema è forse l’elemento più importante, che viene utilizzato per gestire tutti i possibili punti di vista e quindi facilita lo sviluppo iterativo e incrementale del sistema durante tutto il suo ciclo di vita.

L’architettura è un insieme di decisioni significative riguardanti:

• organizzazione del sistema software;
• selezione degli elementi strutturali che compongono il sistema e le loro interfacce;
• il comportamento di questi elementi, specificato in cooperazione con altri elementi;
• comporre questi elementi strutturali e comportamentali in sottosistemi sempre più grandi;
• stile architettonico che guida e determina l'intera organizzazione del sistema: elementi statici e dinamici, le loro interfacce, la cooperazione e il modo in cui si combinano.

L'architettura di un sistema software copre non solo tutti gli aspetti strutturali e comportamentali, ma anche l'uso, la funzionalità, le prestazioni, la flessibilità, la riusabilità, la completezza, i limiti e i compromessi economici e tecnologici e le questioni estetiche.

Vista dal punto di vista dei precedenti La visualizzazione dei casi d'uso copre i casi d'uso che descrivono il comportamento del sistema osservato da utenti finali, analisti e tester. Questo tipo specifica non la vera organizzazione del sistema software, ma quelle forze motrici da cui dipende la formazione dell'architettura del sistema. In UML, gli aspetti statici di questo tipo sono trasmessi dai diagrammi dei casi d'uso e gli aspetti dinamici dai diagrammi di interazione, stato e azione.

Visualizzazione disegno(Vista progettazione) copre le classi, le interfacce e le collaborazioni che formano il vocabolario del problema e delle sue soluzioni. Questa visione supporta principalmente i requisiti funzionali del sistema, ovvero i servizi che deve fornire agli utenti finali. Utilizzando UML, gli aspetti statici di questo tipo possono essere trasmessi mediante diagrammi di classi e oggetti, mentre gli aspetti dinamici mediante diagrammi di interazione, stato e azione.

Visualizzazione del processo(Vista processo) copre i thread e i processi che formano i meccanismi di concorrenza e sincronizzazione nel sistema. Questa visualizzazione descrive principalmente le prestazioni, la scalabilità e il throughput del sistema. In UML, i suoi aspetti statici e dinamici sono visualizzati dagli stessi diagrammi della vista progettazione, ma con particolare attenzione alle classi attive che rappresentano i thread e i processi corrispondenti.

Vista dell'implementazione La vista di implementazione copre i componenti e i file utilizzati per creare e rilasciare il prodotto software finale. Questa visualizzazione è destinata principalmente alla gestione della configurazione di versioni del sistema composte da componenti e file (in una certa misura) indipendenti che possono essere combinati insieme in modi diversi. In UML, gli aspetti statici di questo tipo vengono trasmessi utilizzando i diagrammi dei componenti, mentre gli aspetti dinamici vengono trasmessi utilizzando i diagrammi di interazione, stato e azione.

Visualizzazione della distribuzione La vista di distribuzione copre i nodi che formano la topologia hardware del sistema su cui viene eseguito. Si occupa principalmente della distribuzione, fornitura e installazione delle parti che compongono il sistema fisico. I suoi aspetti statici sono descritti da diagrammi di distribuzione e i suoi aspetti dinamici da diagrammi di interazione, stato e azione.

Ognuna di queste tipologie può essere considerata completamente indipendente, in modo che chi è coinvolto nello sviluppo del sistema possa concentrarsi sullo studio solo di quegli aspetti dell'architettura che lo riguardano direttamente. Ma non dobbiamo dimenticare che queste specie interagiscono tra loro. Ad esempio, i nodi di una vista di distribuzione contengono i componenti descritti per la vista di implementazione, che a loro volta rappresentano l'incarnazione fisica delle classi, delle interfacce, delle collaborazioni e delle classi attive nelle viste di progettazione e processo. UML consente di visualizzare ciascuna delle cinque visualizzazioni elencate e le relative interazioni.