Fondamenti di Ingegneria del Software: Processi, Requisiti e Modellazione UML

1. Cos’è l’Ingegneria del Software?

È un insieme di teorie, metodi e strumenti, sia di tipo tecnologico che amministrativo, per lo sviluppo, la manutenzione e la messa in opera di **software di qualità**, il tutto in tempi e costi preventivati.

2. Definizione di Processo

Un **processo** definisce chi svolge, quando svolge e come viene svolta un’azione.

3. Cos’è un Processo di Sviluppo Software?

Un processo software è un insieme strutturato di attività richieste per sviluppare un sistema software; è un processo **intellettuale e creativo**.

4. Modello a Cascata (Waterfall Model)

Questo modello è caratterizzato da una sequenza rigida di fasi. I punti che lo contraddistinguono sono:

• Definizione e analisi dei requisiti: Si verifica la fattibilità e si tracciano i requisiti.
• Progettazione del sistema e del software: Si progetta prima il sistema e poi la struttura del software.
• Programmazione e test dei moduli: Si sviluppa il software (ex-novo o riciclando parti), si testa e si verifica che rispetti le specifiche di consegna.
• Integrazione e test del software nel sistema: Si integra il software assicurandosi che funzioni come richiesto nelle specifiche, poi si procede alla consegna al cliente.
• Installazione e manutenzione: Il software viene installato presso il cliente, si verificano i problemi di funzionamento e si provvede alla sistemazione di eventuali malfunzionamenti futuri entro un tempo prestabilito.

I difetti principali di questo modello sono la sua **rigidità** (difficile apportare modifiche una volta avviato) e l’obbligo di terminare una fase prima di poter passare alla successiva.

5. Agile Software Development

È un modello che privilegia l’uso di **iterazioni di sviluppo**. Il progetto software è basato su unità chiamate **iterazioni** che durano da 1 a 4 settimane.

Incoraggia la collaborazione e comunicazione tra i membri del team e utilizza lo stato del software come metodo primario di misurazione dell’avanzamento del processo, producendo meno documentazione di altri processi.

Ogni iterazione è un progetto software comprensivo di progettazione, sviluppo, test e rilascio (di una versione incompleta ma stabile) dopo il quale vengono rivalutate le priorità di progetto.

Capisaldi del Modello Agile:

• Soddisfazione del cliente tramite emissioni di software utile più frequente (es: settimanale invece di mensile).
• Il **software funzionante** è il metodo principale di misura dell’avanzamento del processo.
• Intima e giornaliera collaborazione e cooperazione tra i membri del team.
• Predilezione per la comunicazione **faccia a faccia** piuttosto che cartacea o tramite altre piattaforme.
• Fiducia e motivazione tra i membri del team.
• Continua attenzione all’**eccellenza tecnica** e alla buona progettazione.
• Semplicità.
• Flessibilità.
• Team **auto-organizzati**.

6. Sviluppo Iterativo: Pro e Contro

È un procedimento che ha come obiettivo ottenere qualcosa di funzionante nel minor tempo possibile: la progettazione viene migliorata fino a quando il sistema non è completo.

Tecniche Utilizzate:

• Vaporware
• Componenti usa e getta
• Moduli dummy
• Prototipazione rapida tramite **RAD** (Rapid Application Development)
• Rifinitura incrementale

PRO:

• Successo per progetti di piccola/media grandezza.
• Successo per parti di progetti più grandi (es: interfaccia utente).
• Successo per sistemi con un breve ciclo di vita.

CONTRO:

• Progetti spesso **mal strutturati**.
• Assenza di una visione di progetto.
• Possibile richiesta di competenze particolari (es: RAD).

7. Extreme Programming (XP)

È il modello più conosciuto e utilizzato e si basa sulla suddivisione degli scenari nelle **storie degli utenti** implementandole come una serie di task.

I programmatori lavorano in coppia ed effettuano **continuo test** sul codice appena integrato nel sistema. Infatti, prima vengono scritti i test da effettuare sul codice (tramite appositi strumenti) e solo dopo il codice stesso.

C’è una frequente **reingegnerizzazione** del software e lo sviluppo procede a piccoli passi incrementali senza un rigido schema di fasi da rispettare.

Attività Fondamentali di XP:

1. Pianificazione
2. Progettazione
3. Sviluppo
4. Testing

8. Unified Process (UP)

Si tratta di una struttura estensibile che dovrebbe essere personalizzata all’azienda o addirittura al progetto.

Caratteristiche Principali:

• **Iterativo e incrementale**: le fasi principali sono divise in iterazioni temporali (tranne l’inception).
• Basato su **Casi d’uso** e scenari di utilizzo.
• Focalizzato sull’**architettura** del sistema.
• Focalizzato sui **rischi**: si pone molta attenzione ai rischi facendone un’analisi nelle prime iterazioni della fase di elaborazione.

9. Fasi dell’UP

• Inception Phase: Viene fatta una stima grossolana del progetto esaminando i requisiti tramite use case per riuscire a dare una stima approssimativa di tempi e costi.
• Elaboration Phase: Vengono analizzati i rischi e si producono use case, sequence e class diagram. Alla fine di questa fase il progetto deve essere stabile e corrispondente alle specifiche rilasciate dal cliente; deve inoltre possedere tutti i diagrammi necessari alla prossima fase, quella di sviluppo software.
• Construction Phase: Viene sviluppato il software a partire dai diagrammi prodotti nella fase precedente. Lo sviluppo del progetto è suddiviso in iterazioni, al termine delle quali è prodotta una versione eseguibile (seppur magari incompleta) del progetto.
• Transition Phase: Avviene la consegna con il cliente e l’eventuale training/testing dal quale si ricava l’opinione del cliente utile per apportare modifiche e/o miglioramenti.

10. Model Driven Development (MDD)

Si tratta di un modo di sviluppo in cui la stesura del codice rispecchia un **modello teorico** di come dovrà essere il programma.

PRO:

• È utilizzato dove sono richieste particolari validazioni di sicurezza prima della messa in funzione del programma.

CONTRO:

• Può risultare difficile definire l’interfaccia utente tramite un modello.
• Necessita di sapere come fare la stesura di un modello di questo tipo.

11. Model Driven Architecture (MDA)

Si tratta di un modello più “agile” per lo sviluppo di software nel campo del **Domain Engineering**. Secondo questo modello, inizialmente vi è una fase in cui le specifiche vengono descritte in modo testuale e solo successivamente in modo iterazionale con le seguenti fasi:

1. Produzione del **CIM/PIM** (Computational/Platform Independent Model).
2. Produzione a partire dal CIM/PIM del **PDM** (Platform Dependent Model).
3. Sviluppo del software.
4. Testing/Consegna.

12. Cos’è un Requisito?

Un requisito può spaziare dalla descrizione di una nuova funzionalità a quella di una specifica funzione matematica e può servire come:

• Base per fare un’offerta.
• Base per l’intero progetto.

13. Ingegneria dei Requisiti

È il sistema utilizzato per **raccogliere ed analizzare** le descrizioni delle funzionalità e dei vincoli che il sistema deve rispettare.

14. Tipologie di Requisiti

I requisiti possono essere classificati in base a diverse caratteristiche:

Basati sulle caratteristiche del sistema:

• De... (Nota: La classificazione sembra incompleta nel testo originale)

Basati sulla staticità/dinamicità del sistema:

• Volatili
• Durevoli

Basati sull’utilizzatore:

• Dell’utente
• Di sistema

15. Requisiti Funzionali

Descrivono il **comportamento atteso del sistema**, cioè come il sistema deve comportarsi a certi dati in ingresso o in particolari situazioni.

16. Requisiti Non Funzionali

Descrivono il modo in cui i requisiti fondamentali devono essere implementati e sono suddivisi in 3 categorie:

• Requisiti di prodotto: Specificano come il prodotto deve essere realizzato (velocità di esecuzione, efficienza, affidabilità, …).
• Requisiti organizzativi: Riguardano direttive e politiche aziendali (piattaforma di sviluppo, standard, …).
• Requisiti esterni: Dettati da fattori esterni al sistema e allo sviluppo del progetto (regolamentazioni, certificazioni, requisiti etici, …).

17. Requisiti di Dominio

Derivano dallo specifico sistema sul quale il software viene sviluppato e possono essere sia requisiti fondamentali che non fondamentali. Es: sviluppo di un’interfaccia compatibile con tutti i DB basata sullo standard X.

18. Requisiti Volatili

Si tratta di requisiti che cambiano durante la vita dell’azienda e possono essere suddivisi in 4 categorie:

• Mutevoli: Possono cambiare a fronte di un mutamento di fattori esterni (es: variazione di un finanziamento).
• Emergenti: Requisiti che possono emergere a fronte di una maggiore comprensione sul funzionamento del sistema da parte del cliente.
• Consequenziali: Causati dall’implementazione del sistema stesso in azienda.
• Di compatibilità: Causati dalla dipendenza del sistema da particolari altri sistemi già presenti in azienda che, evolvendosi, richiedono che anche il sistema si evolva.

19. Requisiti Durevoli

Requisiti di lunga durata derivati dall’attività principale del sistema. Possono derivare da modelli di dominio. Es: requisiti per dottori in un ospedale.

20. Requisiti dell’Utente

Descrizione dei servizi e dei vincoli del sistema in modo comprensibile anche ad utenti che non hanno particolari competenze tecniche. Sono descritti in modo meno formale tramite testo, tabelle, grafici.

21. Requisiti di Sistema

Descrizione dei requisiti degli utenti espressa in modo più dettagliato e tecnico. È rivolto al cliente e agli sviluppatori e può essere utilizzato come **contratto** tra cliente e fornitore.

22. Il Documento dei Requisiti

Si tratta di un documento che raccoglie tutti i requisiti identificati nel sistema. Descrive dunque **cosa il sistema deve fare (non come lo fa)**.

Se tratta anche requisiti hardware si parla di System Specification, altrimenti di **Software Requirements Specification (SRS)**.

Caratteristiche che i Requisiti dovrebbero rispettare:

• Completi: Devono descrivere ogni aspetto delle funzionalità richieste.
• Consistenti: Non devono presentare conflitti o contraddizioni tra di loro nelle descrizioni delle specifiche.
• Comprensibile: Dovrebbero essere comprensibili alla maggior parte degli interessati, compito non facile dal momento che ingegneri ed utenti normali interpretano in modo differente.
• Esplicito: Non deve presentare mancanze o ambiguità in quanto ciò che una persona dà per scontato può non esserlo per un altro individuo e viceversa.

Tutto questo rende abbastanza difficile la realizzazione di questo documento.

23. Conflitti nel Documento dei Requisiti

I conflitti nelle specifiche sono frequenti e spesso involontari. Es: in un’astronave si desidera un circuito composto da pochi chip per risparmiare peso, ma si desidera anche che questi chip consumino poco per risparmiare energia; ciò è una contraddizione in quanto per avere chip che consumano poco ma svolgono la stessa funzione ne dovrò utilizzare di più, entrando in conflitto con la prima richiesta.

24. Problemi del Linguaggio Naturale (Non Formale)

• Ambiguità.
• Alto rischio di conflitti: I requisiti vengono scritti in modo poco rigido e schematico e tendono a specificare in modo diverso la stessa richiesta andando così a creare dei conflitti.
• Mancanza di modularità.
• Amalgamazione: Requisiti diversi scritti assieme in modo confuso.

La soluzione è adottare uno standard anche nel linguaggio naturale utilizzando parole chiave per i vincoli (shall/should/can), le azioni dell’utente (must/may), l’ambiente (will/might), il rischio di incontrare modifiche (expected to/could).

25. Parti del Processo di Ingegneria dei Requisiti

Il processo si compone di quattro fasi principali:

• Estrazione
• Analisi
• Validazione
• Gestione

26. Processo di Estrazione

Identifica le fonti più importanti per trarre requisiti, le elabora e ne estrae una frase che li descriva. Ciò aiuta il cliente a definire meglio ciò che vuole e le sue priorità e l’ingegnere a focalizzarsi sul problema corretto.

Modalità di Approccio all’Estrazione:

• Campionamento: Raccoglie esempi di documentazione e ne estrae campioni a caso o secondo uno specifico criterio (stratificazione).
• Osservazione dell’ambiente di lavoro: Consiste nell’osservare le abitudini lavorative degli utenti per trarre i requisiti. Occorre stare accorti nell’osservazione in quanto un utente potrebbe comportarsi in un modo diverso se si sente osservato.
• Questionario: Questionario a cui sottoporre gli utenti le cui domande possono essere:
  • Aperte
  • A risposta multipla
• Intervista: Intervista a cui sottoporre gli utenti individualmente, la quale può essere di 2 tipi:
  • Non strutturata: Si lascia all’intervistato la libertà di condurre la conversazione.
  • Strutturata: Formata da un susseguirsi di domande di tipo: Aperto o A risposta multipla.

27. Processo di Analisi dei Requisiti (e l’Analysis Model)

Si tratta di un processo che consente una migliore comprensione dei requisiti da parte degli sviluppatori per favorirne lo sviluppo, il riuso e la manutenzione. Esso raffina il linguaggio naturale dei requisiti schematizzandolo tramite diagrammi di flusso.

28. Analisi: Use Case

Lo **Use Case** descrive tramite figure chiamate **attori** e **interazioni** rispettivamente le persone o gli enti esterni coinvolti nel sistema e le interazioni tra essi. Queste interazioni rappresentano le azioni compiute dagli utenti del sistema al fine di utilizzarne una funzionalità.

29. Linee Guida per la Costruzione degli Use Cases

Identificazione degli Attori:

• Identificare gli attori e i sistemi che dipendono dalle funzionalità del sistema.
• Identificare entità esterne che sono in collegamento diretto con il sistema.
• Identificare gli attori con un nome.

Cosa deve includere uno Use Case:

• Stato di partenza e di fine.
• Pre e post condizioni.
• Flusso principale.
• Flusso/i alternativi.
• Punto di partenza e di fine.
• Attori coinvolti.
• Interazioni tra gli attori.
• Eventuali problemi di progettazione.

Linee Guida per un Buon Use Case:

• Sviluppare il modello senza pensare al modo in cui verrà implementato.
• Introdurre tutti i possibili scenari di uno use case (incluse le eccezioni e come risolverle).
• Nominare uno use case con un **verbo** per enfatizzare che si tratti di un processo.
• Evitare use case troppo specifici (es. “Stampa” invece di “Stampa una ricevuta”).
• Descrive meccanismi, non politiche.

30. Classi di Analisi

Le classi di analisi sono un’**astrazione** di una o più classi reali da realizzare. Esse gestiscono i requisiti funzionali.

Tecniche per Individuare le Classi di Analisi:

• Nome-verbo: Si associano i nomi a classi, attributi e istanze e i verbi a funzioni e relazioni.
• Tramite Use Case: Simile a Nome-verbo ma utilizzando rispettivamente attori e interazioni.
• Carte CRC: Basata su carte rappresentanti le classi, ognuna di queste divisa in: nome, responsabilità, collaboratori della classe.
• Approccio misto: Vengono utilizzate tutte le tecniche sopracitate.

31. Processo di Validazione

Serve ad assicurarsi che i requisiti rispecchino effettivamente il volere del cliente, degli utenti o di chiunque faccia parte del sistema. Ciò si può realizzare in diversi modi:

• Ricontrollo dei requisiti: Frequente ricontrollo dei requisiti coinvolgendo cliente e sviluppatore.
• Prototipazione: Utilizza dei prototipi di sistema atti a testare il corretto comportamento atteso dal programma.
• Generazione di test-case: Vengono creati dei test specifici per controllare il corretto funzionamento di ogni requisito del programma.

32. Processo di Gestione

Si occupa della **gestione del cambiamento** dei requisiti in corso d’opera. In particolare, si deve occupare di:

• Mantenere i costi nel budget.
• Stimare il costo del progetto in base ai requisiti.
• Gestire la **volatilità** dei requisiti.
• Gestire la configurazione dei requisiti di sistema.
• Negoziare i cambiamenti di requisiti e ristimare il costo del progetto a fronte dei nuovi requisiti.

Gestione di una Modifica ai Requisiti:

Quando viene richiesta una modifica dei requisiti si dovrebbe:

1. Analizzare la richiesta e proporre una soluzione.
2. Valutare i cambiamenti e i costi derivati dal cambio di requisiti.
3. Aggiornare i documenti dipendenti dai requisiti per aggiornarne l’implementazione.

33. Scopo dello Studio di Fattibilità

Lo studio di fattibilità viene eseguito per verificare se il progetto sia realizzabile o meno in termini di:

• Utilità alla ditta.
• Rientro dei costi nel budget.
• Tempi di realizzazione accettabili.
• Sviluppabilità utilizzando la tecnologia corrente.
• Possibilità di integrazione con i sistemi già presenti in azienda.

34. Rischi dell’Ingegneria dei Requisiti

• Difficoltà ad individuare i requisiti.
• Incomprensione del vero problema.
• Difficoltà a risolvere i conflitti tra requisiti.
• Cambiamento rapido dei requisiti.
• Tendenza a **strafare** (eccesso di requisiti).

35. Cos’è UML?

**Unified Modeling Language** è uno standard per la visualizzazione, creazione, mantenimento e documentazione di artefatti di un sistema software complesso. Fornisce diversi tipi di diagrammi che consentono di visualizzare diversi tipi di dettaglio dell’architettura del sistema.

Perché UML è Utile:

• Estensibile: Permette un buon grado di estensione della notazione da parte degli utilizzatori.
• Semplice: Non richiede particolari competenze per essere utilizzato.
• Consistente: I diagrammi sono realizzati secondo uno standard preciso e chiaro che non consente di creare ambiguità.
• Utile: Riguarda solo gli elementi dell’ingegneria del software.
• Espressivo: È applicabile ad un largo spettro di sistemi e metodi.

36. Specifiche dell’UML

UML è basato su:

• Infrastruttura: Linguaggio formale.
• Struttura: Costrutti a livello utente (es: diagrammi UML).
• Object Constraint Language (OCL): Linguaggio formale utilizzato per descrivere particolari requisiti che non è possibile descrivere con precisione in un diagramma.
• Interscambio di diagrammi: Facilità nella condivisione di documenti conformi all’UML.

37. Diagrammi UML

I diversi diagrammi UML servono a vedere il progetto sotto diversi punti di vista e sono:

• Use Case View
• Behavioral View
• Structure View
• Implementation View
• Environmental View

38. Use Case View

Si tratta del diagramma UML più utilizzato perché descrive, tramite **attori** e **interazioni**, le funzionalità del sistema.

Gli utenti (persone o macchine) che interagiscono con il sistema sono indicati con figure solitamente a forma di omino stilizzato chiamate **attori**. Le azioni compiute dagli utenti sono rappresentate con degli ovali contenenti la descrizione dell’azione. Collegando attori e interazioni tramite linee (continue o tratteggiate) si creano azioni, estensioni e dipendenze. Sulle linee può essere indicata anche la **molteplicità** dell’azione.

Il sistema viene rappresentato nell’use case da un **rettangolo vuoto** contenente le interazioni degli utenti con lo stesso.

39. Structural View: Diagrammi Componenti

È composta da:

• Class Diagram
• Object Diagram
• Composite Structural Diagram
• Package Diagram

Structural View: Class Diagram

Si tratta di un diagramma **statico** che descrive le classi con i loro attributi, firme dei metodi (non contenuto) e le relazioni che ci sono fra esse. Ogni classe è rappresentata con un rettangolo suddiviso in:

• Nome
• Attributi: Nella forma “<+/-> <NomeAttributo>:<TipoAttributo>” dove +/- indica rispettivamente se l’attributo è pubblico o privato.
• Metodi: Nella forma “<+/-> <NomeMetodo>:<TipoValoreDiRitorno>” dove +/- indica rispettivamente se il metodo è pubblico o privato.

Relazioni tra le Classi:

• Composizione e Aggregazione: Rappresentano oggetti formati da oggetti più piccoli rispettando il paradigma “whole/part”. La differenza è l’intensità del legame: nell’aggregazione (rombo vuoto) l’eliminazione del padre non elimina i figli; nella composizione (rombo pieno) l’eliminazione del padre porta all’eliminazione di tutti i figli.
• Associazione: Indica l’associazione tra due classi (solitamente dovuta ad una lista nella classe di partenza della freccia). Legate da una freccia continua con la punta vuota.
• Generalizzazione: Indica l’ereditarietà. Legate da una freccia continua con la punta piena che va dalla classe che eredita a quella ereditata.
• Realizzazione (implementazione): Indica una classe che implementa un’altra classe. Legate da una freccia tratteggiata con la punta piena che va dalla classe che implementa a quella implementata.
• Nidificazione (sottoclasse): Indica una sottoclasse (inner class). Legate da una linea continua che termina con un pallino diviso da una croce che va dalla classe interna a quella padre.

Structural View: Object Diagram

Si tratta della realizzazione di un Class Diagram; invece di rappresentare i tipi di valori che un attributo può assumere, ne contiene uno specifico valore. Lo si può intendere come una **fotografia ad un certo istante** del sistema. Non è molto utilizzato se non nella documentazione dei test.

Structural View: Composite Structural Diagram

Viene utilizzato per descrivere la struttura interna di un **classificatore** (un componente UML composto da parti, porte e connessioni e che descrive una funzionalità). Questo diagramma è simile al diagramma delle classi ma mostra solo uno specifico utilizzo delle stesse.

Componenti del Composite Structural Diagram:

• Classificatore: Solitamente una classe, rappresentato con un rettangolo.
• Parti: I ruoli giocati in fase di esecuzione di un’istanza della classe. Rappresentate con dei rettangoli.
• Porte: Punti di interazione per collegare le parti tra loro o verso l’esterno. Rappresentati con dei quadratini.
• Interfacce fornite: Rappresentate con delle linee con un cerchio verso l’esterno.
• Interfacce richieste: Rappresentate con delle linee con una mezzaluna verso l’esterno.

Structural View: Package Diagram

Serve ad organizzare in gruppi e sottogruppi gli elementi in modo da evidenziare relazioni e dipendenze delle varie parti del sistema. Può essere utilizzato:

• Suddividendo gli artefatti per **funzionalità** (un package per ogni funzionalità).
• Suddividendo gli artefatti per **fasi di sviluppo** (ogni package conterrà gli artefatti relativi ad una certa fase).

44. Behavioral View: Diagrammi Principali

Si occupa di descrivere le **interazioni dinamiche** tra i componenti del sistema nell’implementazione dei requisiti. È composto da:

• Sequence Diagram
• Communication (Collaboration) Diagram
• Robustness Diagram
• Interaction Overview Diagram
• State Diagram
• Activity Diagram
• Timing Diagram

Behavioral View: Sequence Diagram

Rappresenta il modo in cui gli oggetti interpretano un processo, tramite:

• Ruoli: Gli oggetti rappresentati come rettangoli contenenti il proprio nome.
• Linee vita (life line): Linee tratteggiate che partono dal ruolo e scorrono verso il basso indicando l’avanzamento temporale.
• Attivazioni: Periodi lungo la life line rappresentati da stretti rettangoli che indicano il lasso di tempo durante il quale il ruolo è impiegato a svolgere un’azione.
• Messaggi: Frecce orizzontali che indicano l’interazione tra i ruoli (chiamate ai metodi).
• Fragments: Riquadri che raccolgono più messaggi e servono a mutare l’andamento lineare del diagramma. Tipi comuni: Alt (alternativa), Loop (ciclo), Opt (procedimento alternativo condizionale), Par (esecuzione in parallelo), Region (regione critica per il multithreading).

Behavioral View: Communication (Collaboration) Diagram

È simile al Sequence Diagram, rappresenta le interazioni tra gli oggetti ma è **incentrato sul numero di interazioni e su cosa viene trasferito** piuttosto che sul loro ordine temporale. Non vi sono life line, ma associazioni tra oggetti lungo le quali viene specificato, tramite una freccia, cosa viene passato e il loro ordine nel processo.

Behavioral View: Robustness Diagram

È un Communication o Sequence Diagram semplificato e serve ad identificare tutti gli oggetti necessari allo sviluppo oltre che a verificare la correttezza e la completezza (anche per i flussi alternativi) degli use cases. È composto da cerchi, elementi di controllo, interfacce ed entità.

Behavioral View: Activity Diagram

È un **diagramma di flusso** rappresentante le attività intraprese da un oggetto, indicando eventuali biforcazioni (**fork**, esecuzioni in parallelo) e conseguenti ricongiungimenti (**join**) o decisioni indicate da un rombo. Presenta un punto di inizio (pallino nero) e uno di fine (cerchio con un pallino al centro).

Behavioral View: State Machine Diagram

Rappresenta tutti gli **stati** che un oggetto attraversa a seguito di eventi esterni ad esso. È composto da:

• Stati: Rettangoli arrotondati con il nome dello stato.
• Transizioni: Frecce da uno stato all’altro.
• Punto iniziale e finale: Indicati rispettivamente con un pallino nero e un cerchio con un pallino al centro.
• Scelte: Rombo.
• Giunzioni (pseudo stato): Pallino nero a cui arrivano e da cui partono molteplici frecce.
• Composizioni: Rettangoli arrotondati che contengono intere parti del diagramma.

Behavioral View: Interaction Overview Diagram

(Il testo originale indica “Non so cosa sia”.)

Behavioral View: Timing Diagram

Utilizzato per mostrare il **comportamento nel tempo** dei vari oggetti ed, eventualmente, le loro interazioni e/o vincoli temporali. Somiglia vagamente ai grafici temporali presenti nei datasheet.

52. Implementation View

Descrive l’implementazione della Structural View, può contenere artefatti implementativi come file di codice, file di dati, librerie. È rappresentato tramite un **Component Diagram** che illustra le parti di software che compongono il programma.

53. Environment View

Rappresenta la **topologia hardware** del sistema, la sua configurazione e come questa si interfaccia col software. È utile per trarre parametri statistici quali l’affidabilità, la scalabilità, la sicurezza, ecc…

Viene illustrata tramite un **Deployment Diagram**, il quale descrive la configurazione hardware in termini di nodi e connessioni, relazione fisica tra hardware e software, il modo in cui il software è stato installato e come si muove all’interno della macchina.

54. Cos’è OCL?

**Object Constraint Language** è un linguaggio formale tipizzato (ma non di programmazione) che consente di descrivere ciò che un diagramma UML non riesce a descrivere con sufficiente precisione mantenendo un adeguato grado di scrittura/lettura da parte delle aziende. OCL è basato sui **vincoli**.

55. Cos’è un Vincolo?

Un vincolo è una condizione che impone una **restrizione** su uno o più valori di un modello/sistema orientato agli oggetti. Un vincolo si dice rispettato quando la condizione imposta risulta essere vera. Un vincolo **non ha effetti collaterali**, cioè non altera lo stato del sistema. Sintassi e semantica di un vincolo sono formalizzate e non lasciano spazio ad ambiguità.

56. Vincolo Invariante

È un vincolo legato ad un elemento del modello. Deve valere per tutte le istanze di tale modello e deve essere vero per tutto il tempo in cui l’istanza **non è in esecuzione (a riposo)**.

57. Precondizione

È un vincolo che deve rivelarsi vero al momento della **chiamata di un’operazione**. È compito del chiamante assicurarsi che tale vincolo sia rispettato prima di chiamare; il chiamato può scatenare errori di programmazione per segnalare che il vincolo non è stato rispettato qualora accadesse ciò.

58. Postcondizione

È un vincolo che deve essere vero **dopo il completamento dell’operazione**. Si tratta del duale della precondizione.

59. Vincolo di Guardia

È un vincolo che deve essere vero **prima dell’avvio di una transizione** (come una precondizione). È utilizzato particolarmente negli Activity e State Diagram.