Scarica Object-Oriented Software Engineering Using UML, Patterns, and Java e più Appunti in PDF di Programmazione Avanzata solo su Docsity!
Introduction to Software Engineering The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists. Il termine ingegneria del software è stato coniato nel 1968 come una risposta allo stato di desolazione in cui verteva l'arte di sviluppare software di qualità nei tempi e nel budget. Gli sviluppatori del software non erano in grado di fissare obiettivi concreti, per prevedere le risorse necessarie per raggiungere tali obiettivi e gestire le aspettative dei clienti. L'accento in “ingegneria del software” si pone su entrambe le parole, sia su software che su ingegneria. Un ingegnere è in grado di costruire un prodotto di alta qualità utilizzando componenti off-the-shelf e integrandoli in tempi previsti e secondo i vincoli di bilancio. L’ingegnere si trova spesso di fronte a una cattiva definizione dei problemi e davanti a soluzioni parziali e spesso deve anche basarsi su metodi empirici per valutare soluzioni. La complessità e la modifica I sistemi software utili sono sistemi complessi. Per essere utili hanno bisogno di evolversi di pari passo con i bisogni utenti finali hanno bisogno e dell'ambiente di destinazione. Introduzione al Software Engineering: Software Engineering Failure Si prendono in considerazione i seguenti esempi [Neumann, 1995]: Bug dell’anno 1900 Nel 1992, Mary di Winona, Minnesota, ha ricevuto un invito a partecipare a una scuola materna. Maria è stata 104 al momento. Bug dell’Anno bisestile Un supermercato è stato multato di $1000 per carne avente circa 1 giorno in più, il 29 febbraio 1988. Il programma del computer che stampava la data di scadenza per le etichette della carne non ha tenuto conto del fatto che il 1988 è stato un anno bisestile. Uso improprio di interfaccia il 10 aprile 1990, a Londra, un treno della metropolitana lasciò la stazione senza il suo conducente. Il conducente aveva fissato con nastro adesivo il pulsante che avviava il treno, basandosi sul sistema che impediva al treno di muoversi quando le porte erano aperte. L'operatore aveva lasciato il suo treno per chiudere una porta che si era bloccata, e quando la porta si è chiusa, il treno è semplicemente partito. Sicurezza Il CERT (Computer Emergency Response Team) al Software Engineering Institute è un’organizzaizone governativa finanziata per assistere la comunità nel trattare con gli incidenti di protezione, vulnerabilità e la protezione del know-how. Il numero degli incidenti di sicurezza riportati al CERT dagli Stati Uniti sono aumentate da 252 incidenti nel 1990 a 21,756 nel 2000 e più di 40.000 incidenti sono stati riportati nel
In ritardo e non rispettando il bilancio preventivo nel 1995, bug nel sistema automatico dei bagagli del nuovo aeroporto internazionale di Denver ha quasi determinato la distruzione delle valigie. L'aeroporto è aperto 16 mesi di ritardo, con una spesa aggiuntiva di 3,2 miliardi di dollari, e un sistema di gestione dei bagagli prevalentemente manuale.
In ritardo e non rispettando il bilancio preventivo (2) Nel 2002, il Swanick sistema di controllo del traffico aereo copre tutto il lungo il tragitto del traffico aereo in Inghilterra e Galles. Il sistema è stato consegnato sostanzialmente sforando il preventivo di bilanico bilancio (costo £623 milioni inizialmente prevista a £ 350 milioni di euro) e in ritardo di 6 anni. Due importanti aggiornamenti del sistema sono stati consegnati dopo la che la gestione del traffico era già iniziata. Il rispetto dei tempi di consegna Un sistema software dopo diciotto mesi di sviluppo e 200 milioni di dollari è stato consegnato a una compagnia di assicurazione sanitaria in Wisconsin nel 1984. Tuttavia il sistema non funzionava correttamente: per cui sono stati pagati $60 milioni di dollari in più e si son dovuti impiegare 3 anni per ottimizzare il sistema. Inutili complessità il C-17 aereo-cargo costò $500 milioni di euro a causa di problemi con il software avionico. Il C-17 prevedev 19 computer di bordo, 80 microprocessori e 6 diversi linguaggi di programmazione. Che cosa è l’Ingegneria del Software? Ciascuno dei bug sopra descritto è causato da un problema relativo al software. In alcuni casi gli sviluppatori non prevedono situazioni che si verificano raramente (una persona che vive più di 100 anni, gli anni bisestili che influiscono sulle date di scadenza), oppure in altri casi non prevedono che l’utente abusi del sistema (tenere premuto un pulsante, sfruttare falle di sicurezza nel software di rete), o non prevedono guasti di sistema causati da errori di gestione (sforare bilancio consegna, rispettare i tempi di consegna di un sistema non corretto, inutili complessità). I sistemi software sono complesse creazioni che svolgono molte funzioni ; essi sono costruiti per realizzare e raggiungere molti obiettivi diversi e spesso conflittuali tra loro. Essi comprendono molti componenti che spesso sono realizzati su misura attraverso il lavoro di partecipanti esperti di diverse. Il processo di sviluppo e di ciclo di vita del software spesso si estende a molti anni. Infine, i sistemi complessi sono difficili da capire completamente da ogni singola persona. Molti sistemi sono così difficili da comprendere, anche durante la loro fase di sviluppo, che essi non hanno mai finito: questi sono chiamati vaporware. I progetti di sviluppo del software sono soggetti a continue modifiche. Poiché i requisiti sono complessi, hanno bisogno di essere aggiornati quando vengono scoperti gli errori e ogni volta che gli sviluppatori comprendono meglio l'applicazione. Se la progettazione ha una durata di molti anni, il personale di direzione ha un’alta probabilità di fare dietrofront, e richiede una costante formazione perché il tempo dei cambiamenti tecnologici è spesso inferiore alla durata del progetto. La radicata idea di un manager di progetto che tutte le modifiche siano state affrontate e che i requisiti possano essere congelati porterà alla distribuzione di un sistema irrilevante. Che cosa si intende per software engineering? L’Ingegneria del Software è una attività di modellazione. Gli ingegneri di software per gestire la complessità attraverso la modellazione, si concentrano in tutti i momenti solo sui dettagli rilevanti e ignorano tutto il resto. In corso di sviluppo, gli ingegneri di software creano molti modelli diversi del sistema e del dominio dell'applicazione. L’Ingegneria del Software è un’attività di problem-solving. I modelli vengono utilizzati per la ricerca di una soluzione accettabile. Questa ricerca è azionato mediante sperimentazione. Gli ingegneri di software non
- Decidere la soluzione appropriata.
- Specificare la soluzione. L’Ingegneria del Software è una attività di ingegnerizzazione, non algoritmica. Essa richiede la sperimentazione, il riutilizzo delle soluzioni pattern e l'evoluzione incrementale del sistema verso una soluzione che sia accettabile per il client. Lo sviluppo di un software orientato agli oggetti comprende tipicamente sei attività di sviluppo: elicitazione dei requisiti, analisi, progettazione del sistema, progettazione degli oggetti, implementazione e testing. Durante l’elicitazione dei requisiti e l'analisi, gli ingegneri del software formulano il problema con il cliente e creano il dominio di applicazione del modello. L’elicitazione dei requisiti e l’analisi corrispondono alle fasi 1 e 2 del metodo ingegneristico. Durante la progettazione del sistema gli ingegneri del software analizzano il problema, lo suddividono in pezzi più piccoli e selezionano le strategie generali per la progettazione del sistema. Durante la progettazione degli oggetti, essi selezionano i dettagli delle soluzioni per ogni pezzo e decidono la soluzione più appropriata. La progettazione del sistema e la progettazione degli corrispondono alle fasi 3 e 4 del metodo ingegneristico. Durante la fase di implementazione, gli ingegneri del software realizzano il sistema traslando la soluzione del modello di dominio in una rappresentazione eseguibile. L’implementazione corrisponde alla fase 5 del metodo ingegneristico. Ciò che rende il problem solving del software engineering diverso da quello di altre scienze è che il cambiamento si verifica nel dominio applicativo e in quello delle soluzioni mentre il problema viene risolto. Anche lo sviluppo del software include attività il cui scopo è quello di valutare l'adeguatezza dei rispettivi modelli. Durante l'analisi, il modello del dominio applicativo viene confrontato con la realtà del cliente, cosa che a sua volta potrebbe cambiare come risultato di modellazione. Durante la revisione del progetto, il modello del dominio delle soluzioni viene valutato sulla base degli obiettivi del progetto. Durante il test il sistema è convalidato rispetto il modello del dominio delle soluzioni, che potrebbe essere modificato mediante l'introduzione di nuove tecnologie. Durante la gestione di progetto, i responsabili confrontano il loro processo di sviluppo del modello (cioè la pianificazione di progetto e il budget) con la realtà (cioè il lavoro consegnato prodotti e risorse disponibili). Acquisizione delle conoscenze Un errore comune che gli ingegneri di software e fanno è quello di presumere che l'acquisizione delle conoscenze necessarie per sviluppare un sistema sia lineare. Questo errore non è fatto solo dal software manager; esso può essere trovato anche in altre aree. L’acquisizione di conoscenza è un processo non lineare. L’aggiunta di un nuovo elemento di informazione può invalidare tutte le conoscenze che si erano acquisite per la comprensione di un sistema. Anche se si era già documentata la comprensione in documenti e codice, bisogna essere mentalmente preparato a ripartire da zero. Ciò ha importanti implicazioni sull’insieme di attività e le loro interazioni per sviluppare il software di sistema. Ci sono diversi processi software che hanno a che fare con questo problema evitando le dipendenze sequenziale insita nel modello a cascata. Il Risk-based development è basato sul tentativo di anticipare le sorprese in ritardo in un progetto, identificando i componenti più a rischio. L’ Issue-based development si basa sui tentativi di rimuovere del tutto la linearità. Qualsiasi attività di sviluppo-analisi, progettazione di sistema o di oggetti, implementazione, test o la consegna può influenzare qualsiasi altra attività. Nell’Issue- based development, tutte queste attività vengono eseguite in parallelo. La difficoltà dei modelli di sviluppo non sequenziali è che essi sono difficili da gestire.
Logica Gli ingegneri del software fanno ipotesi su di un sistema che cambia costantemente. Anche se i modelli del dominio applicativo eventualmente stabilizzano sviluppatori nell’acquisire una adeguata comprensione del problema, i modelli del dominio delle soluzioni sono in costante evoluzione. I fault di progettazione e l’implementazione scoperti durante i test di usabilità e i problemi riscontrati durante la valutazione dell'utente provocano dei cambiamenti nei modelli delle soluzioni. Le modifiche possono essere causate anche da nuove tecnologie. Le modifiche introdotte dalle nuove tecnologie spesso consentono la formulazione di nuovi requisiti funzionali o non funzionali. Un tipico compito di ingegneri del software è quello di modificare il software di un sistema operativo corrente per incorporare questa nuova tecnologia. Per modificare il sistema, non è sufficiente capire le sue componenti attuali e il suo comportamento. È anche necessario acquisire e comprendere il contesto in cui ogni decisione progetto è stata presa. Questa conoscenza aggiuntiva è chiamata il fondamento logico del sistema. L’acquisizione e l’accesso alla logica di un sistema non è banale. In primo luogo, per ogni decisione presa possono essere considerate, valutate e sostenute numerose alternative. Di conseguenza, la logica rappresenta una maggiore quantità di informazioni rispetto a quanto non facciano i modelli di soluzione. Secondo le informazioni logiche spesso non sono esplicite. Gli sviluppatori prendono molte decisioni basate sulla loro esperienza e intuizioni, senza valutare esplicitamente diverse alternative. I concetti dell’Ingegneria del Software Un progetto il cui scopo è quello di sviluppare un sistema software, è composto da un certo numero di attività. Ogni attività è a sua volta composto da un certo numero di compiti. Un compito consuma risorse e produce un WorkProduct. Un WorkProduct può essere sia un sistema, che un modello o un documento. Le risorse sono i partecipanti, il tempo o le apparecchiature. Ogni rettangolo rappresenta un concetto. Le linee tra i rettangoli rappresentano diverse relazioni tra i concetti. Per esempio, la forma a diamante indica l'aggregazione: il progetto prevede una serie di attività che comprende un certo numero di compiti. Il triangolo indica una generalizzazione di rapporto; i partecipanti, il tempo e le attrezzature sono specifici tipi di risorse. I partecipanti e i ruoli Nello sviluppo di un sistema di software si richiede la collaborazione di molte persone con diversi background e interessi. Il cliente ordina e paga per il sistema. Gli sviluppatori costruiscono il sistema. Il project manager di pianifica budget del progetto e coordina gli sviluppatori e il cliente. Gli utenti finali sono supportati dal sistema. Ci si riferisce a tutte le persone coinvolte nel progetto come partecipanti e si fa riferimento a una
erogazione comprende un software di installazione e di attività di un operatore attività di formazione. Le attività sono a volte chiamate anche le fasi. Un compito rappresenta una unità atomica di lavoro che può essere gestita : un manager assegna a uno sviluppatore, lo sviluppatore lo svolge, e il manager controlla il progresso e il completamento delle attività. Le attività consumano risorse, risultati in WorkProduct e dipendono dal lavoro di prodotti fabbricati da altre attività. Le risorse sono attività che sono utilizzate per portare a termine un lavoro. Le risorse includono il tempo, le attrezzature aziendali e la manodopera. Durante la pianificazione di un progetto, un manager si suddivide il lavoro in compiti e li assegna alle risorse. Requisiti funzionali e non funzionali I requisiti specificano un set di funzioni che il sistema deve avere. Un requisito funzionale è una specifica di una funzione che il sistema deve supportare, mentre un requisito non funzionale è un vincolo per il funzionamento del sistema che non è direttamente correlato a una funzione del sistema. Per esempio, “l'utente deve essere in grado di acquistare biglietti” e “L'utente deve essere in grado di accedere alle informazioni tariffarie” sono i requisiti funzionali. “L'utente deve essere fornito un feedback in meno di un secondo” e “I colori utilizzati nell'interfaccia deve essere coerente con i colori della società” sono requisiti non funzionali. Altri requisiti non funzionali possono includere l’uso di specifiche piattaforme hardware per il sistema, requisiti di sicurezza come “Il sistema deve gestire guasti e anomalie” e come garantire la compatibilità con le versioni precedenti con un vecchio sistema che il cliente non è disposto sostituire. Notazioni, Metodi e Metodologie Una notazione è un insieme di regole grafico o testuale per la rappresentazione di un modello. L'alfabeto romano è una notazione per la rappresentazione delle parole. UML ( Unified Modeling Language ), è una notazione per la rappresentazione dei modelli object-oriented. I diagrammi di flusso sono una notazione teorica per la rappresentazione di sistemi in termini di sorgenti di dati, data sinks, e trasformazioni dei dati. Un metodo è una tecnica ripetibile che specifica le fasi coinvolte nella risoluzione di un problema specifico. Una ricetta è un metodo per la cottura di un piatto specifico. Un algoritmo di ordinamento è un metodo per ordinare gli elementi di una lista. La gestione razionale è un metodo per giustificare il cambiamento. La gestione della configurazione è un metodo per il rilevamento del cambiamento. Una metodologia è una raccolta di metodi per la risoluzione di una classe di problemi e consente di specificare come e quando ogni metodo deve essere utilizzato. Un libro di cucina a base di pesce con una raccolta di ricette è una metodologia per la preparazione del pesce se essa contiene anche consigli su come gli ingredienti devono essere utilizzati e che cosa fare se non tutti gli ingredienti sono disponibili. La metodologia di Royce, la Tecnica della Modellazione degli Oggetti (OMT [Rumbaugh et al., 1991]), la metodologia di Booch [Booch, 1994], e la Catalysis [D'Souza & Testamenti, 1999] sono le metodologie object-oriented per lo sviluppo di software. Metodologie di sviluppo del software si decompongono il processo in attività. L’OMT fornisce metodi per tre attività: analisi , che si concentra sulla formalizzazione dei requisiti di sistema in un modello di oggetto, la progettazione del sistema che si concentra sulle decisioni strategiche e progettazione degli oggetti , che trasforma il modello di analisi in un modello di oggetto che può essere implementato. La metodologia OMT presuppone che i requisiti siano stati già definiti e non fornisce i metodi per stimolare i requisiti. La Unified Software Development Process include anche un’attività di analisi e tratta la progettazione del sistema e la progettazione degli oggetti come una singola attività chiamata semplicemente Design. Lo Unified Software Development Process, a differenza dell’OMT, include un’attività
di raccolta dei requisiti per l’elicitazione e la modellazione dei requisiti. Catalysis, invece di usare le stesse notazioni dello Unified Software Development Process, si concentra più sul riutilizzo del design e del codice utilizzando pattern e framework. Tutte queste metodologie si concentrano sulla gestione di sistemi complessi. Attività di Sviluppo Software Elicitazione dei Requisiti Durante L’elicitazione dei requisiti, i clienti e gli sviluppatori devono definire lo scopo del sistema. Il risultato di questa attività è una descrizione del sistema in termini di attori e casi di uso. Gli attori rappresentano le entità esterne che interagiscono con il sistema, e comprendono ruoli come utenti finali e altri computer con cui il sistema ha a che fare e l'ambiente. I casi di uso in generale sono sequenze di eventi che descrivono tutte le azioni possibili tra un attore e il sistema di una data funzionalità. Analisi Durante l'analisi, gli sviluppatori hanno l’obiettivo di produrre un modello del sistema che sia corretto e completo, coerente e non ambiguo. Gli sviluppatori trasformare i casi di uso prodotti la fase di elicitazione dei requisiti in un modello a oggetti che descrive completamente il sistema. Durante questa attività, gli sviluppatori scoprono le ambiguità e le incoerenze nel caso d’uso modello che risolvono con il cliente. Il risultato dell’analisi è un modello di sistema annotato con attributi, operazioni e associazioni. Progettazione del sistema Durante la progettazione del sistema gli sviluppatori definiscono gli obiettivi di progettazione e scompongono il sistema in sottosistemi più piccoli in modo che possano essere realizzati dai singoli team. Gli sviluppatori possono inoltre selezionare le strategie per la costruzione del sistema, come ad esempio la piattaforma hardware/software su cui verrà eseguito il sistema e la stratedia di persistenza e gestione dei dati. Il risultato della progettazione del sistema è una chiara descrizione di
diversità dei partecipanti, per via della loro distribuzione geografica e a causa della complessità delle informazioni scambiate. Per affrontare i problemi di comunicazione, i partecipanti hanno molti strumenti disponibili, fra cui la tecnica di adottare diverse convenzioni: quando i partecipanti convengono su notazioni per la rappresentazione di informazioni sugli strumenti per la manipolazione delle informazioni, hanno già eliminato notevoli fonti di incomprensione. Esempi di notazioni includono diagrammi UML, modelli per la scrittura di documenti e verbali di riunioni e programmi di identificazione per la denominazione dei componenti software. Gestione della logica La gestione della logica è la giustificazione delle decisioni. Data una decisione, la sua logica include il problema che è stato affrontato, le alternative che gli sviluppatori hanno considerato, i criteri che gli sviluppatori hanno utilizzato per valutare le alternative, il dibattito agli sviluppatori hanno affrontato per ottenere il consenso e la decisione. La logica è l’informazione più importante di cui gli sviluppatori hanno bisogno quando devono apportare alcune modifiche al sistema. Se un criterio cambia, gli sviluppatori sono in grado di rivalutare tutte le decisioni che dipendono da questo criterio. Se diventa disponibile una alternativa, essa può essere confrontata con tutte le altre alternative che sono già state valutate. Purtroppo, la logica è anche la cosa più complessa da trattare per sviluppatori durante la fase di sviluppo e quindi la più difficile da aggiornare e mantenere. Per affrontare questa sfida, gli sviluppatori acquisiscono informazioni sulla logica nel corso di incontri e discussioni on line, rappresentano la logica con i modelli di emissione, e la logica di accesso durante le modifiche. Gestione della Configurazione Software Per gestione della configurazione software si intende il processo che controlla e gestisce le modifiche nei WorkProduct. Le modifiche pervadono lo sviluppo del software. I requisiti cambiano in base alle richieste del cliente e in base a come gli sviluppatori migliorano la loro comprensione del dominio applicativo. La piattaforma hardware/software su cui il sistema è costruito cambia in base all’evoluzione della tecnologia. La gestione della configurazione consente agli sviluppatori di tenere traccia delle modifiche apportate. Il sistema è rappresentato da un numero di elementi di configurazione che sono indipendentemente rivisto. Per ogni elemento di configurazione, la sua evoluzione è registrato come una serie di versioni. La gestione della configurazione consente inoltre agli sviluppatori di controllare i cambiamenti. Dopo che una linea di base è stato definita, qualsiasi modifica deve essere valutata e approvata prima di essere attuata. Project Management Il Project management non produce di per sé alcun artefatto. Al contrario, il project management include la supervisione delle attività che garantiscono la consegna di un sistema di alta qualità rispettando i vincoli di tempo e di budget Ciclo di Vita del Software In questa parte si descrive l’ingegneria del software come una attività di modellazione. Gli sviluppatori costruiscono modelli dei domini di applicazione e soluzione per affrontare la loro complessità. Ignorando i dettagli irrilevanti e concentrandosi solo su ciò che è rilevante per un problema specifico, gli sviluppatori possono in modo più efficace di risolvere i problemi e rispondere alle domande.
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.
Diagrammi di interazione I diagrammi di interazione sono usati per formalizzare il comportamento dinamico del sistema e per visualizzare la comunicazione tra oggetti. Essi sono utili per identificare oggetti aggiuntivi che partecipano in casi di utilizzo. Gli oggetti coinvolti in un caso d’uso si chiamano oggetti partecipanti. Un diagramma di interazione rappresenta le interazioni che avvengono tra questi oggetti. Per esempio, la figura sovrastante è una speciale forma di interazione schema denominato un diagramma di sequenza per il caso d’uso SetTime dell’esempio Orologio. La colonna più a sinistra rappresenta l'attore WatchUser, ovvero chi avvia il caso d'uso. Le frecce etichettate rappresentano gli stimoli che un attore o un oggetto invia ad altri oggetti. In questo caso il WatchUser preme il pulsante due volte 1 e il pulsante 2 una volta per impostare il suo orologio un minuto avanti. Il caso d’uso SetTime termina quando l’attore WatchUser preme contemporaneamente entrambi i pulsanti. Diagrammi di stato I diagrammi di stato sono utili per descrivere il comportamento dinamico di un singolo oggetto come un numero di stati e transizioni tra questi stati. Uno stato rappresenta un particolare insieme di valori per un oggetto. Dato uno stato, una transizione rappresenta il futuro stato in cui l’oggetto può spostarsi e le condizioni associate con il cambiamento di stato. Nella figura sovrastante è rappresentato un diagramma di stato per l’esempio Watch. Un piccolo cerchio nero in BlinkHours indica lo stato iniziale. Un cerchio concentrico al cerchio nero indica che StopBlinking è uno stato finale. Questo schema rappresenta informazioni diverse rispetto al diagramma della sequenza della figura precedente: il diagramma di sequenza si concentra sui messaggi scambiati tra gli oggetti come risultato di eventi esterni creati da attori, mentre il diagramma di stato si concentra sulle transizioni tra stati come risultato di eventi esterni per un singolo oggetto.
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
corsivo. In Java, Collection è una classe astratta che fornisce una generalizzazione per tutte le classi di Collection. Tuttavia, non ci sono istanze della classe Collection. Piuttosto, tutti gli oggetti da collezione sono istanze di una delle sottoclassi di raccolta, come LinkedList, ArrayList o HashMap. Si noti che non tutte le generalizzazioni sono classi astratte. Una classe definisce le operazioni che possono essere applicati alle sue istanze. Inoltre le operazioni di una superclasse possono essere ereditate e applicate agli oggetti della sottoclasse. Una classe definisce gli attributi che si applicano a tutte le sue istanze. Un attributo è n Named Slot nell’istanza in cui un valore è memorizzato. Gli attributi hanno un nome univoco all'interno della classe e del tipo. Un oggetto è una istanza di una classe. Un oggetto ha un’identità e memorizza i valori dell’attributo. Ogni oggetto appartiene esattamente ad una classe. In UML, un esempio è rappresentato da un rettangolo con il suo nome sottolineato. Event class, Event, Messages Le Event Class sono astrazioni che rappresenta un tipo di evento per il quale il sistema ha una risposta comune. Un evento, un'istanza di una event class, è un evento rilevante nel sistema. L’invio di un messaggio è il meccanismo mediante il quale l’oggetto mittente richiede l'esecuzione di una operazione nell’oggetto ricevente. Il messaggio è composto da un nome e un numero di argomenti. L'oggetto ricevente corrisponde al nome del messaggio in una delle sue operazioni e passa gli argomenti per l'operazione. I risultati vengono restituiti al mittente. Gli eventi e i messaggi sono istanze : essi rappresentano le occorrenze concrete nel sistema. Le event class sono astrazioni che descrivono gruppi di eventi per i quali il sistema ha una risposta comune. In pratica, il termine "eventi" può fare riferimento a istanze o a classi. Questa ambiguità è risolta esaminando il contesto in cui il termine viene usato. Modellazione Orientata agli Oggetti Il dominio applicazione rappresenta tutti gli aspetti del problema di un utente. Questo include l'ambiente fisico, gli utenti e le altre persone, i loro processi di lavoro e così via. È abbastanza importante per gli analisti e gli sviluppatori comprendere il dominio applicativo di un sistema in modo che esso possa svolgere il suo compito in modo efficace. Il dominio delle soluzioni è la modellazione spazio di tutti i possibili sistemi. La Modellazione nel dominio delle soluzioni rappresenta le attività design del sistema e design dell’oggetto nello sviluppo del progetto. Il modello del dominio delle soluzioni è molto più ricco e più volatile rispetto al modello del dominio applicativo, perché il sistema è solitamente modellato in modo molto più dettagliato rispetto al dominio di applicativo. L'analisi object-oriented ha a che fare con la modellazione del dominio applicativo. Il design Object- oriented si occupa della modellazione del dominio delle soluzioni. Entrambe le attività di modellazione usano lo stesso tipo di rappresentazione (cioè, le classi e gli oggetti). Nell’analisi e nel design orientato agli oggetti, il modello del dominio applicativo è anche parte del modello di sistema. Modellare il dominio applicativo e il dominio delle soluzioni con una singola notazione presenta vantaggi e svantaggi. Da un lato essa può essere una potente soluzione: le classi soluzione che rappresentano i concetti di applicativi possono corrispondere al dominio applicativo, ed inoltre, queste classi possono essere incapsulate in sottosistemi indipendenti da altri concetti di implementazione (ad es., interfaccia utente e tecnologia di database) e confezionate in un toolkit riutilizzabile di classi di dominio. Dall’altra parte, utilizzare una singola notazione può creare confusione perché elimina la distinzione tra il mondo reale e il modello. La soluzione di dominio è destinato ad essere più semplice e spinto verso la soluzione. Per risolvere questo problema, si utilizza una singolo di notazione e in caso di ambiguità, si può distinguere tra i due domini. Falsificazione e Prototipazione Un modello è una semplificazione della realtà nel senso che in esso i dettagli irrilevanti sono ignorati. I dettagli pertinenti, tuttavia, hanno bisogno di essere rappresentati. La Falsificazione è il processo attraverso cui si
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.
della collezione. Gli oggetti sono entità che incapsulano lo stato e il comportamento. Ogni oggetto ha una identità: può essere riferito individualmente ed è distinguibile da altri oggetti. In UML le classi e gli oggetti sono rappresentati da rettangoli divisi in tre parti. Nella parte superiore si visualizza il nome della classe o dell'oggetto, nella parte centrale si inseriscono i suoi attributi ed in quella inferiore si inseriscono le sue operazioni. La parte relativa agli attributi e quella relativa alle operazioni possono essere omesse. I nomi degli oggetti sottolineati indicano che essi sono istanze. Per convenzione, i nomi delle classi iniziano con una lettera maiuscola. Gli oggetti nei diagrammi degli oggetto possono essere rinominati (seguita dalla loro classe) per essere più facilmente indicati. In tal caso, il loro nome comincia con una lettera minuscola. Il tipo di un attributo è utilizzato per specificare la gamma di valori validi che un attributo può assumere. Si osserva che i tipi di attributo non sono essenziali per la definizione del sistema, infatti la decisione sul tipo dell’attributo può essere rimandata fino l momento della progettazione. Questo consente agli sviluppatori di concentrarsi sulla funzionalità del sistema e ridurre al minimo il numero di modifiche banali quando la funzionalità del sistema viene modificata. Associazioni e collegamenti Un collegamento rappresenta una relazione tra due oggetti. Le associazioni sono relazioni tra classi e rappresentano gruppi di collegamenti. In UML le associazioni possono essere simmetriche (bidirezionale) o asimmetrico (unidirezionale). il poligono. UML consente di mettere le frecce su entrambe le estremità di un'associazione. Per convenzione, tuttavia, un'associazione senza frecce indica che la navigazione è supportato in entrambe le direzioni. Associazione di classi Le associazioni sono simili alle classi, nel fatto che essi possono avere attributi e operazioni ad esse associati. Tale associazione è chiamata classe di associazione ed è rappresentata da un simbolo di classe che contiene gli attributi e le operazioni ed è collegata al simbolo di associazione con una linea tratteggiata. Qualsiasi associazione di classe può essere trasformato in una classe con associazioni semplici. Ruoli Ciascuna estremità di una associazione può essere marcato con un ruolo. L’etichettatura alla fine delle associazioni con i ruoli ci permette di distinguere tra le associazioni multiple provenienti da una classe. Inoltre, i ruoli chiariscono lo scopo dell'associazione. Molteplicità Ciascuna estremità di una associazione può essere marcato con un insieme di numeri interi che indica il numero di collegamenti che possono legittimamente provenire da una istanza della classe connessa all'associazione. Questo insieme di numeri interi è chiamato la molteplicità dell’associazione.
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.
