Scarica Capitolo 2 tradotto Prentice Object Oriented Software Engineering Using UML Patterns and Java 3rd 2012 e più Appunti in PDF di Programmazione Avanzata solo su Docsity!
Modellazione con UML Every mechanic is familiar with the problem of the part you can’t buy because you can’t find it because the manufacturer considers it a part of something else. Le notazioni consentono di articolare idee complesse in modo conciso e preciso. In progetti che coinvolgono molti partecipanti, spesso di differenti tecniche e culturali, la precisione e la chiarezza sono aspetti critici dato che il costo di comunicazione aumenta rapidamente. Perché una notazione consenta una comunicazione precisa, deve essere ben definita da una semantica precisa, deve essere adatta a rappresentare un dato aspetto di un sistema e deve essere ben compresa dai partecipanti al progetto. In quest'ultimo punto si trova la forza degli standard e delle convenzioni: quando una notazione è usata da un gran numero di partecipanti, vi è poco spazio per interpretazioni e ambiguità. Al contrario, quando esistono molti dialetti di una notazione, o quando è usata una notazione molto specializzata, gli utenti sono inclini a giungere a malintesi perché ogni utente impone la propria interpretazione. Si è scelto l'UML (Unified Modeling Language) come una notazione primaria perché fornisce un’ampia gamma di notazioni per rappresentare i diversi aspetti di un sistema. Introduzione UML è una notazione nata dall'unificazione dell’Object Modelling Technique e dell’Object-Oriented Software Engineering. UML è stato anche influenzato da altre notazioni object-oriented. L'obiettivo di UML è quello di fornire una notazione standard che può essere utilizzata da tutti i metodi object-oriented per selezionare e integrare i migliori elementi delle notazioni precedenti. UML è stato progettato per una vasta gamma di applicazioni, quindi, esso fornisce costrutti per una vasta gamma di sistemi e attività. Lo sviluppo del sistema si concentra su tre diversi modelli di sistema:
- Il modello funzionale , rappresenta in UML i diagrammi di caso d'uso, descrive le funzionalità del sistema dal punto di vista dell'utente.
- Il modello di oggetti , rappresenta in UML i diagrammi di classe, descrive la struttura del sistema in termini di oggetti, gli attributi e le associazioni e le operazioni. Durante i requisiti e analisi, il modello di oggetti parte come analysis object model descrive l'applicazione dei concetti relativi al sistema. Durante la progettazione del sistema il modello di oggetto viene raffinato nel system design object model e include le descrizioni delle interfacce del sottosistema. Durante la progettazione degli oggetti, il modello viene raffinato nell’ object design model e comprende le descrizioni dettagliate di soluzione oggetti.
- Il modello dinamico , rappresenta in UML diagrammi di interazione, diagrammi di stato e diagrammi di attività, e descrive il comportamento interno del sistema. I diagrammi di interazione descrivono il comportamento come una sequenza di messaggi scambiati tra un insieme di oggetti, considerando che i diagrammi di stato descrivono il comportamento in termini di stati e le possibili transizioni tra stati. I diagrammi di attività descrivono il comportamento in termini di controllo e i flussi di dati. Diagrammi dei casi d’uso I diagrammi dei casi d’uso vengono utilizzati durante l’elicitazione dei requisiti e l’analisi per rappresentare la funzionalità del sistema. I casi d’uso focalizzano l’attenzione sul comportamento del sistema da un punto di vista esterno. Un caso d’uso descrive una funzione fornita dal sistema che produce un risultato visibile per un attore. Un attore corrisponde a qualsiasi entità che interagisce con il sistema. L'identificazione degli attori e dei casi d’uso si risolve nella definizione dei confini del sistema, cioè nel differenziare le attività eseguite dal sistema e le attività compiute dal suo ambiente. Gli attori sono al di fuori del confine del sistema, considerando che i casi di uso sono all'interno del confine del sistema.
Figura 1. Un diagramma dei casi d’uso in UML che descrive la funzionalità di un semplice Orologio. L'attore WatchUser può consultare l'ora sul suo orologio (con l'uso ReadTime caso) o impostare il tempo (con le SetTime caso d'uso). Tuttavia, solo l'attore WatchRepairPerson può cambiare la batteria dell’orologio (con il caso d’uso ChangeBattery). Diagrammi delle Classe I diagrammi delle classi sono utilizzati per descrivere la struttura del sistema. Le classi sono astrazioni che consentono di specificare la struttura comune e il comportamento di un insieme di oggetti. Gli oggetti sono istanze di classi che vengono creati, modificati ed eliminati durante l'esecuzione del sistema. Un oggetto ha uno stato che include i valori dei suoi attributi e i suoi legami con altri oggetti. I diagrammi di classe descrivono il sistema in termini di oggetti, classi, attributi, operazioni e le loro associazioni. Per esempio, in figura c’è un diagramma di classe che descrive gli elementi di tutti gli orologi della classe SimpleWatch. Questi guarda tutti gli oggetti hanno un'associazione a un oggetto della classe a pulsante, un oggetto della classe Display e un oggetto della classe di tempo e un oggetto della classe della batteria. I numeri sulle estremità delle associazioni indicano il numero di collegamenti di ciascun oggetto SimpleWatch può avere con un oggetto di una determinata classe. Per esempio, un SimpleWatch ha esattamente due pulsanti e un display, due batterie, e una sola volta. Analogamente, tutti i pulsanti, display, tempo, batteria e gli oggetti vengono associati con esattamente un oggetto SimpleWatch. A livello di analisi, le associazioni rappresentano l'esistenza di relazioni. Per esempio, un SimpleWatch richiede il corretto numero di pulsanti, display, batterie e tempo. In questo esempio, l'associazione è simmetrica: pulsante non può svolgere la sua funzione senza un SimpleWatch. UML consente anche rapporti monodireionali.
Activity Diagram Un diagramma delle attività descrive il comportamento di un sistema in termini di attività. Le attività sono elementi di modellizzazione che rappresentano la esecuzione di una serie di operazioni. L'esecuzione di un'attività può essere attivata mediante il completamento di altre attività, dalla disponibilità di oggetti o da eventi esterni. I diagrammi di attività sono simili ai diagrammi di flusso per il fatto che essi possono essere usati per rappresentare il flusso di controllo (cioè, l'ordine in cui si verificano operazioni) e del flusso di dati (vale a dire, gli oggetti che vengono scambiati tra le operazioni). La figura sovrastante è un diagramma di attività che rappresenta le attività correlate alla gestione di un incidente. I rettangoli arrotondati rappresentano attività; le frecce tra le attività rappresentano il flusso di controllo e le spesse barre rappresentano ila sincronizzazione del flusso di controllo. Il diagramma di attività in figura mostra che AllocateResources, CoordinateResources e DocumentIncident possono essere avviati solo dopo che l’attività OpenIncident sia completata. Analogamente ArchiveIncident può essere avviata solo dopo il completamento di AllocateResources, Coordinate–Resources e DocumentIncident. Questi ultimi tre attività, tuttavia, possono verificarsi simultaneamente. I concetti di modellazione Sistemi, modelli e viste Un sistema è un insieme organizzato parti comunicanti. Ad esempio un auto, composta da quattro ruote, un telaio, un corpo e un motore, è progettato per il trasporto di persone, oppure un orologio, composto da una batteria e un circuito è progettato per misurare il tempo. Le parti di un sistema possono essere a loro volta considerate come sistemi più semplici chiamati sottosistemi. Il motore di una macchina è composto da cilindri, pistoni, un modulo iniezione e molte altre parti, è un sottosistema della vettura, e analogamente il circuito integrato di un orologio sono sottosistemi. Questo decomposizione dei sottosistemi può essere applicata in modo ricorsivo per i sottosistemi. Gli oggetti rappresentano la fine di questa ricorsione, quando ogni pezzo è abbastanza semplice da poterlo comprendere pienamente senza ulteriore decomposizione. Molti sistemi sono realizzati da numerosi sottosistemi interconnessi in modalità complicate, spesso così complessi che nessuno sviluppatore è in grado di gestire la sua interezza da solo. La modellazione è un mezzo per affrontare questa complessità. I sistemi complessi sono generalmente descritti da più di un modello, ognuno incentrato su un diverso aspetto o il livello di precisione. Modellare significa costruire un'astrazione di un sistema che si concentra su aspetti interessanti e ignora i dettagli irrilevanti. Ciò che è interessante o irrilevanti varia in base a cosa capita per mano. La modellazione di ci consente di affrontare la complessità attraverso approccio divide et impera : per ogni tipo di problema che si desidera risolvere, si costruisce un modello che si concentra solo sulle questioni rilevanti per il problema. Generalmente, la modellazione si concentra sulla creazione di un modello che è abbastanza semplice per essere gestito da una sola persona. Una regola empirica è che ogni entità deve contenere al massimo 7 ± 2 parti. La modellazione aiuta anche a gestire le complessità consentendo di affinare i modelli semplici in maniera incrementale in altri modelli più dettagliati e più vicini alla realtà. In ingegneria del software, come in tutte le discipline di ingegneria, il modello di solito precede il sistema. Durante l'analisi, prima di tutto bisogna creare
un modello di ambiente e delle funzionalità comuni che il sistema deve fornire, ad un livello che è comprensibile da parte del client. Poi bisogna perfezionare questo modello, aggiungere maggiori dettagli sulle forme che il sistema deve visualizzare, il layout dell'interfaccia utente e la risposta del sistema a casi eccezionali. La serie di tutti i modelli costruiti durante la fase di sviluppo è chiamato il modello del sistema. Se si decide di non utilizzare i modelli, e di iniziare direttamente con la codifica del sistema lontano, si devono specificare tutti i dettagli dell'interfaccia utente prima che il client possa fornire dei feedback e quindi, in questo modo quando il client quindi introduce delle modifiche significherebbe perdere molto tempo e sprecare risorse. Purtroppo, anche un modello può diventare molto complesso e non più facilmente comprensibile. Si potrebbe continuare a utilizzare il metodo divide et impera in modo da raffinare il modello complesso in modelli più semplici. La view si concentra su un sottoinsieme di un modello per renderlo comprensibile. Le notazioni regole sono grafiche o testuali che rappresentano vedute le view. Un diagramma di classe UML è una visualizzazione grafica del modello a oggetti. In UML i diagrammi di classe, un rettangolo con un titolo rappresenta una classe. Una linea tra due rettangoli rappresenta una relazione tra le due classi corrispondenti. Nell’ingegneria del software, vi sono molte altre notazioni per la modellazione di sistemi. UML descrive un sistema in termini di classi, eventi, membri, le interazioni e le attività. I diagrammi di flusso illustrano il modo in cui i dati sono recuperati, elaborati e memorizzati. Tipi di Dati, Tipi di Dati Astratti e Istanze Un tipo di dato è un’astrazione nel contesto di un linguaggio di programmazione. Un tipo di dato ha un nome univoco che consente di distinguerlo da altri tipi di dati. Esso denota un insieme di valori che sono membri del tipo di dati (vale a dire, le istanze del tipo di dati) e definisce la struttura e le operazioni valide per tutte le istanze del tipo di dati. I tipi di dati vengono utilizzati nei linguaggi tipizzati per assicurare che solo le operazioni valide vengono applicate a casi specifici. Per esempio, il nome int 32 in Java corrisponde a tutti i valori interi nell’intervallo tra - 232 e 232 - 1. Un tipo di dati astratto è un tipo di dati definito da una specifica implementazione indipendente. I tipi di dati astratti consentono agli sviluppatori di ragionare su una serie di istanze senza guardare una specifica implementazione del tipo di dati astratto. Esempi di tipi di dati astratti sono insiemi e sequenze che possono essere matematicamente definiti. Un sistema può fornire implementazioni diverse implementazioni del tipo di dati astratto, ciascuno che ottimizza diversi criteri (ad esempio, il consumo di memoria, tempo di inserimento). Tuttavia, uno sviluppatore che utilizza un determinato set ha bisogno di capire solamente la sua semantica e non ha la necessità di conoscere la rappresentazione interna del set. Classi, Classi Astratte e Oggetti Una classe è un'astrazione della modellazione object-oriented e nei linguaggi di programmazione orientati agli oggetti. Come i tipi di dati astratti, una classe incapsula sia la struttura che il comportamento. A differenza dei tipi di dati astratti, le classi possono essere definite in termini di altre classi tramite ereditarietà. Si supponga di avere un orologio che può anche funzionare come una calcolatrice. La classe CalculatorWatch può quindi essere visto come un affinamento della classe Watch. Questo tipo di relazione tra una classe di base e di una classe raffinata è denominata eredità. La generalizzazione di una classe (es., Watch) è chiamata superclasse, la classe specializzata (ad esempio, CalculatorWatch) è chiamato sottoclasse. In un rapporto di ereditarietà, la sottoclasse affina la superclasse definendo nuovi attributi e operazioni. Superclasse e sottoclasse sono termini relativi. La stessa classe può essere una sottoclasse rispetto a una classe e una classe superiore rispetto a un'altra classe. Quando un rapporto di ereditarietà serve solo per il modello attributi condivisi e operazioni, cioè se la generalizzazione non è destinata a essere istanziata, la classe risultante è chiamato una classe astratta. Le classi astratte rappresentano spesso i concetti di generalizzati nel dominio applicativo e i loro nomi sono in
dimostra che i dettagli pertinenti sono stati rappresentate in modo errato o non rappresentati affatto e che il modello non corrisponde alla realtà che dovrebbe rappresentare. Si è in grado di applicare la falsificazione allo sviluppo di un sistema software. Per esempio, una tecnica per lo sviluppo di un sistema è la prototipazione : quando si progetta l'interfaccia utente, gli sviluppatori costruiscono un prototipo che simula solo l'interfaccia utente di un sistema. Il prototipo è poi presentato agli utenti potenziali per la valutazione, cioè falsificazione, e successivamente modificata. Nella prima iterazione di questo processo, gli sviluppatori sono propensi a buttare via il prototipo iniziale in seguito al feedback degli utenti. In altri termini, gli utenti falsificano il prototipo iniziale perché non rappresenta accuratamente i dettagli pertinenti. Si noti che è possibile solo dimostrare che un modello non è corretto. Anche se in alcuni casi è possibile dimostrare matematicamente che i due modelli sono equivalenti, non è possibile dimostrare che uno di essi rappresenta correttamente la realtà. I diagrammi dei casi d'uso Casi di uso e attori I protagonisti sono le entità esterne che interagiscono con il sistema. Esempi di attori includono il ruolo di un utente (ad esempio, un amministratore di sistema di un cliente della banca, una banca teller) o un altro sistema (ad esempio, un database centrale, di una linea di fabbricazione). Gli attori hanno nomi e descrizioni univoche. I casi d’uso descrivono il comportamento del sistema dal punto di vista di un attore. Il comportamento descritto dai casi d’uso è anche chiamato comportamento esterno. Un caso d’uso descrive una funzione fornita dal sistema come un insieme di eventi che produce un risultato visibile per gli attori. Gli attori avviano un caso d’uso per accedere alle funzionalità del sistema. Il caso d’uso può quindi avviare altri casi d’uso e raccogliere più informazioni da parte degli attori. Quando gli attori e i casi d'uso si scambiano informazioni dice che essi comunicano. Per la descrizione testuale di un caso d’uso, si usa un modello composto da sei campi adattato da:
- Il nome del caso d’uso è unico in tutto il sistema in modo che gli sviluppatori (e partecipanti al progetto) possano fare riferimento a ogni caso d’uso in modo inequivocabile.
- i soggetti partecipanti sono gli attori che interagiscono con il caso d’uso.
- Condizioni di ingresso descrivono le condizioni che devono essere soddisfatte prima che il caso d’uso inizi.
- Il flusso degli eventi descrive la sequenza di interazioni del caso d'uso, che possono essere numerate per riferimento. Il caso comune (cioè, i casi che sono attese dall'utente) e i casi eccezionali (vale a dire casi inaspettati dall'utente, come gli errori e le condizioni insolite) sono descritti separatamente in diversi casi d’uso per chiarezza. Si organizzano le fasi nel flusso di eventi in due colonne, la colonna a sinistra che rappresenta passi compiuti dall'attore, mentre la colonna di destra che rappresenta i passi realizzati dal sistema. Ciascuna coppia di attore-sistema passi rappresenta un'interazione.
- Le condizioni di uscita che descrivono le condizioni soddisfatti dopo il completamento del caso d'uso.
- i requisiti di qualità sono requisiti che non sono correlati alla funzionalità del sistema. Questi includono vincoli sulle prestazioni del sistema, la sua implementazione, le piattaforme hardware su cui è installato, e così via.
I casi d’uso sono scritti in linguaggio naturale. Questo consente agli sviluppatori di utilizzarli per comunicare con il cliente e gli utenti che generalmente non dispongono di una conoscenza approfondita delle notazioni del software engineering. L'uso di linguaggio naturale consente inoltre ai partecipanti provenienti da altre discipline di comprendere i requisiti del sistema. L'uso di linguaggio naturale consente agli sviluppatori di acquisire le cose, in particolare i requisiti speciali che non possono essere facilmente essere espresse attraverso i diagrammi. I diagrammi dei casi d'uso possono includere quattro tipi di relazioni: comunicazione, inclusione, estensione ed ereditarietà. Relazione di comunicazione Gli attori e i casi d’uso comunicano quando vengono scambiate informazioni tra di loro. La relazione di comunicazione sono rappresentate da una linea continua tra l'attore e il simbolo del caso d’uso. Relazione di inclusione Quando si descrive un sistema complesso, il suo modello dei casi d’uso può diventare molto complesso e a volte addirittura ridondante. Si può ridurre la complessità del modello identificando caratteristiche comuni nei diversi casi d’uso. Relazione di Estensione Le relazioni di estensione sono un mezzo alternativo per ridurre la complessità del modello dei casi. Un caso d’uso può estendere un altro caso d’uso mediante l’aggiunta di eventi. Una relazione di estensione indica che un'istanza del caso d’uso esteso può includere (a determinate condizioni) il comportamento specificato dall'estensione del caso d’uso. Una tipica applicazione di estendere i rapporti è la specifica dei comportamenti eccezionali. Relazione di ereditarietà Una relazione di ereditarietà è un terzo meccanismo per ridurre la complessità di un modello. Un caso d’uso può specializzare un altro più generale aggiungendo ulteriori dettagli. Si osservi che a relazione di estensione e di ereditarietà sono diverse: con l’estensione ogni caso d'uso descrive un diverso flusso di eventi per eseguire un compito diverso. Scenari Un caso d’uso è un’astrazione che descrive tutti i possibili scenari che coinvolgono la funzionalità descritta. Uno scenario è un’istanza di un caso d’uso che descrivere un concreto insieme di azioni. Gli scenari si usano come esempi per illustrare casi comuni e si concentrano sulla comprensibilità. Casi d’uso vengono utilizzati per descrivere tutti i casi possibili e si concentrano sulla completezza. Uno scenario si descrive utilizzando un modello con tre campi:
- Il nome dello scenario che consente di fare riferimento ad esso in modo inequivocabile. Il nome di uno scenario è sottolineato per indicare che si tratta di una istanza.
- le istanze di attori partecipanti che indicano quale istanza di attore è coinvolto in uno scenario.
- Il flusso di eventi di un scenario descrive la sequenza di eventi passo dopo passo. Si osservi che per gli non vi è alcuna necessità di condizioni di entrata o di uscita. Le pre-condizioni e le post- condizioni sono astrazioni che consentono agli sviluppatori di descrivere una serie di condizioni in base alle quali un caso d’uso viene invocato Diagrammi delle classi Classi ed oggetti I diagrammi delle classi descrivere la struttura del sistema in termini di classi e oggetti. Le classi sono astrazioni che specificano gli attributi e il comportamento di un insieme di oggetti. Una classe è una collezione di oggetti che condividono un insieme di attributi che distinguono gli oggetti come membri
Tutti gli EmergencyReport sono scritti da esattamente un FieldOfficer. In altri termini, ciascun oggetto EmergencyReport ha esattamente un link a un oggetto della classe FieldOfficer. La molteplicità delle estremità di associazione reportsGenerated è "molti", indicato attraverso un asterisco. "molti" è molteplicità abbreviata per 0..n. Questo significa che qualsiasi dato FieldOfficer può essere autore di zero o più EmergencyReports. In UML, una estremità di associazione può avere un insieme arbitrario di numeri interi come molteplicità. Per esempio, un'associazione potrebbe consentire solo un primo numero di collegamenti e quindi sarebbe una molteplicità 1, 2, 3, 5, 7, 11, 13 e così via. In pratica, la maggior parte delle associazioni che si incontrano appartengono a uno dei seguenti tre tipi:
- Una associazione uno-a-uno ha una molteplicità 1 su ciascuna estremità. Una associazione uno-a-uno tra due classi significa che esiste esattamente un legame tra le istanze di ogni classe.
- Una associazione uno-a-molti ha una molteplicità 1 su una estremità e 0..n (rappresentato anche da un asterisco o 1..n sull'altro. Una associazione uno-a-molti tra due classi indica la composizione.
- una associazione molti-a-molti ha una molteplicità 0..n o 1..n su entrambe le estremità. L’associazione molti-a-molti tra due classi indica che un numero arbitrario di link possono esistere tra le istanze delle due classi. Questo è il tipo più complesso di associazione. Aggiungere la molteplicità di associazioni aumenta la quantità di informazioni che si raccolgono sia sul dominio applicativo che sul dominio delle soluzioni. Specificare la molteplicità di un'associazione diventa difficile quando si determinano quali casi d’uso sono necessari per manipolare gli oggetti del dominio applicativo. Aggregazione Le associazioni di aggregazione sono utilizzate per rappresentare una vasta gamma di collegamenti tra un insieme di oggetti. In particolare, si verifica frequentemente un caso speciale di associazione: l’aggregazione. Per esempio, uno State contiene molte County, che a loro volta contengono molte Township. Una PoliceStation è composta da molti PoliceOfficers. Una Directory contiene un numero di File. Tali relazioni potrebbero essere modellate utilizzando una associazione uno-a-molti. Invece, UML fornisce il concetto di una aggregazione, indicata da una linea semplice con un diamante in corrispondenza della estremità del contenitore dell'associazione. Le associazioni uno-a-molti e le aggregazioni, sebbene siano simili, non possono essere utilizzate in modo interscambiabile: le aggregazioni indicano aspetti gerarchici del rapporto e può avere molteplicità uno-a-molti o molti-a-molti.
Qualificazione La qualificazione è una tecnica per ridurre la molteplicità usando le chiavi. Le associazioni con molteplicità 0..1 o 1 sono più facili da comprendere rispetto a associazioni con molteplicità 0..n o 1..n. Spesso nel caso di una associazione uno-a-molti, oggetti sul lato "molti" possono essere distinte dall'altro utilizzando un nome. Per esempio, in un sistema di archiviazione gerarchica, ogni file appartiene a esattamente una directory. Ogni file è identificato in modo univoco da un nome nel contesto di una directory. Molti file possono avere lo stesso nome nel contesto del file system; tuttavia, due file non possono condividere lo stesso nome nella stessa directory. Senza qualificazione, l'associazione tra directory e file ha una molteplicità uno dal lato di directory e zero-a-molti dal lato di File. Si può ridurre la molteplicità sul lato di File utilizzando il nome dell’attributo come una chiave , chiamato anche un qualificatore. Il rapporto tra Directory e File è chiamato associazione qualificata. Ridurre le molteplicità è sempre preferibile, poiché più il modello diventa chiaro e meno casi devono essere presi in considerazione. Gli sviluppatori dovrebbero esaminare ciascuna associazione che ha una molteplicità uno-a-molti o molti-a-molti per vedere se un qualificatore può essere aggiunto. Spesso queste associazioni possono essere qualificate con un attributo della classe di destinazione. Ereditarietà L’Ereditarietà è il rapporto tra una classe generale e una o più classi specializzate. L’ereditarietà permette di descrivere tutti gli attributi e le operazioni che sono comuni a una serie di classi. Le sottoclassi ereditano gli attributi e le operazioni dalla loro classe padre. Le classi Abstract si distinguono dalle classi concrete perchè si scrivono in corsivo il nome della classe astratta. Le classi astratte sono utilizzate nella modellazione orientata agli oggetti per classificare i relativi concetti, riducendo così la complessità generale del modello. Il comportamento degli oggetto è specificato dalle operazioni. Un oggetto richiede ad un altro oggetto l'esecuzione di un'operazione inviandogli un messaggio che è accoppiato con un metodo definito dalla classe a cui appartiene l’oggetto ricevente o da uno delle sue superclassi. I metodi di una classe in un linguaggio di programmazione orientato agli oggetti sono le implementazioni di tali operazioni. La distinzione tra operazioni e metodi permette di distinguere tra la specifica del comportamento (cioè, un'operazione) e la sua attuazione (ovvero un insieme di metodi che sono eventualmente definiti in diverse classi nella gerarchia di ereditarietà). Applicare i diagrammi delle classi I diagrammi delle classi sono utilizzati per descrivere la struttura di un sistema. Durante l'analisi, gli ingegneri del software costruiscono diagrammi di classe per formalizzare la conoscenza del dominio applicativo. Le classi partecipanti rappresentano gli oggetti trovati nei casi d’uso e gli schemi di interazione e descrivono i loro attributi e operazioni. Lo scopo dei modelli di analisi è quello di descrivere il campo di applicazione del sistema e scoprire i suoi confini. I modelli di analisi non si concentrano sull'implementazioni. I concetti come informazioni di interfaccia, la comunicazione di rete e persistenza dei dati non sono rappresentati. I diagrammi di classe sono raffinati durante la progettazione del sistema e progettazione degli oggetti per includere le classi che rappresentano il dominio delle soluzioni. Per esempio, lo sviluppatore aggiunge le classi che rappresentano le basi di dati, le
Applicare i diagrammi di interazione I diagrammi di interazione descrivono le interazioni tra i diversi oggetti. Uno dei motivi principali per costruire un diagramma di interazione è voler scoprire le responsabilità delle classi coinvolte nei diagrammi di classe e di scoprire anche nuove classi. In altre parole, il diagramma di interazione aiuta lo sviluppatore nel decidere quali oggetti richiedono operazioni particolari. Tipicamente vi è un diagramma di interazione per ogni caso d’uso con particolare attenzione sul flusso degli eventi. Lo sviluppatore identifica gli oggetti che partecipano al caso d'uso, e assegna i pezzi del comportamento del caso d'uso agli oggetti nel form delle operazioni. Il diagramma delle classi e i relativi diagrammi di interazione sono di solito realizzati in tandem dopo che è stata definita la classe iniziale del diagramma. Questo processo spesso conduce anche a perfezionamenti dei casi d'uso (ad esempio, correzione di descrizioni ambigue, aggiungendo il comportamento mancanti) e di conseguenza la scoperta di più oggetti e più servizi. Diagrammi degli stati Uno stato di macchina in UML è una notazione che permette di descrivere la sequenza degli stati attraverso cui un oggetto passa in seguito ad eventi esterni. Uno stato di macchina in UML è estensione del modello di stati finiti. Da un lato, le macchine a stati forniscono la notazione per il nesting di membri e macchine di stato (cioè, uno stato può essere descritto da una macchina di stato). D'altro canto, le macchine a stati forniscono la notazione delle transizioni dei collegamenti fra i messaggi e le condizioni sugli oggetti. Uno stato è una condizione soddisfatta dagli attributi di un oggetto. In generale, uno stato può essere calcolato dai valori di vari attributi. Una transizione rappresenta un cambiamento di stato attivato da eventi, condizioni o dal tempo. Uno stato è rappresentato da un rettangolo arrotondato. Una transizione è rappresentato da una freccia che apre il collegamento tra due membri. I membri sono etichettati con il loro nome. Un piccolo cerchio nero indica lo stato iniziale. Un cerchio concentrico al piccolo cerchio nero indica lo stato finale. Le azioni sono unità fondamentali di elaborazione che possono acquisire una serie di ingressi, e producono una serie di uscite e possono modificare lo stato del sistema. Le Azioni normalmente prendono un breve lasso di tempo di esecuzione e non sono interrompibili. Per esempio, un'azione può essere realizzata con un'operazione di chiamata. Le azioni possono verificarsi in tre luoghi in una macchina di stato:
- Quando una transizione è preso.
- Quando un membro è inserito.
- Quando un membro viene abbandonata. Durante una fase di transizione, sono eseguite prima le azioni di uscita dallo stato d'origine e poi le azioni associate alla transizione, quindi vengono eseguite azioni di destinazione dello stato. Le azioni di uscita ed entrata vengono sempre eseguite quando un membro viene rispettivamente abbandonata o inseriti. Essi non dipendono dalla transizione specifica che è stata utilizzata per uscire o entrare nello stato. Una transizione interna è un passaggio che non lascia lo stato. Le transizioni interne sono attivati da eventi e possono avere le azioni ad essi associati. Tuttavia, l’accensione di una transizione interna non comporta l'esecuzione di alcuna azione di uscita o ingresso. Un’attività è un insieme coordinato di azioni. Un membro può essere associato un'attività che viene eseguita fin quando un oggetto risiede in uno stato. Mentre un'azione è breve e non interrompibile, una attività può richiedere una notevole quantità di tempo e viene interrotto solo quando una transizione in uscita dallo stato
è iniziata. Le attività sono associate a uno stato etichetta “do” e sono posizionati all’interno dello stato in cui viene eseguita. Per esempio, nella figura count ticks è un'attività associata con lo stato MeasureTime. Uno stato di macchina nidificato di riduce la complessità. Esse possono essere utilizzate al posto delle transizioni interne. In figura il numero corrente è modellato come uno stato di macchina nidificato, mentre le azioni che corrispondono al modificare il numero corrente vengono modellate mediante le transizioni interne. Si osserva che ogni stato potrebbe essere modellato come uno stato di macchina nidificato. Applicare i diagrammi di stato I diagrammi di stato sono usati per rappresentare il comportamento consistente di un sottosistema o di un oggetto. A differenza dei diagrammi di interazione che si concentrano sugli eventi che influenzano il comportamento di un insieme di oggetti, i diagrammi di stato esplicitano quale attributo o insieme di attributi hanno un impatto sul comportamento di un singolo oggetto. Tali diagrammi sono utilizzati per identificare gli attributi dell'oggetto e per perfezionare la descrizione del comportamento di un oggetto mentre i diagrammi di interazione vengono usati per identificare gli oggetti partecipanti e i servizi che essi forniscono. I diagrammi di stato possono essere utilizzati anche durante la progettazione sistema e degli oggetti per descrivere gli oggetti del dominio delle soluzioni che hanno comportamenti interessanti. Diagrammi di attività In UML i diagrammi di attività rappresentano la sequenziazione e il coordinamento dei comportamenti di basso livello. Un diagramma di attività indica il modo in cui un comportamento è realizzato in termini di uno o più sequenze di attività e i flussi di oggetti necessari per coordinare le attività. I diagrammi di attività sono gerarchici: un'attività è realizzata da un'azione o da un grafo di sotto-attività e dal loro flusso di oggetti associato.
Uno stereotipo è un meccanismo di estensione che consente agli sviluppatori di classificare gli elementi del modello in UML. Uno stereotipo è rappresentato dalla stringa racchiusa da virgolette angolate (<>) e allegate al modello di elemento a cui esso si applica, come ad esempio una classe o un'associazione. Formalmente, attaccare uno stereotipo a un elemento del modello è semanticamente equivalente alla creazione di una nuova classe in UML. Questo consente ai modellisti di creare nuovi tipi di blocchi di costruzione che sono necessari nel loro dominio. Per esempio, durante l'analisi, si possono classificare tre tipi di oggetti: <>, <> e <>. Gli oggetti Entity, Control e Boundary hanno la stessa struttura (cioè, essi hanno degli attributi, operazioni e associazioni), ma servono a scopi diversi. Un vincolo è una regola che è attaccato a un modello UML elemento che limita la sua semantica. Questo ci permette di rappresentare fenomeni che altrimenti non potrebbero essere espressi con UML.
