Software Engineering

Transcript

1 Software Engineering

2 Introduzione I processi di sviluppo del software sono molto complessi Un approccio a fasi è necessario per controllarli I possibili modelli in letteratura possono essere Modelli tradizionali, document-driven: nuovi documenti prodotti al termine di ogni fase Modelli evoluzionari, basati su un prototipo che si adatta alle esigenze dell utente e si evolve con esse

3 Perchè usare i cicli di vita Fornire un framework per standardizzare la terminologia, le attività e i prodotti (deliverables) Aumentare la visibilità del progresso del progetto per tutte le parti coinvolte Fornire le basi per il piano di progetto e lo scheduling delle attività Fornire meccanismi per controllare l avanzamento e lo stato del progetto

4 Il giusto ciclo di vita Maggiore velocità di sviluppo Maggiore produttività Maggiore tracciamento e controllo Maggiori relazioni con il cliente Minori rischi di progetto Minori overhead di progetto

5 100 Distribuzione dei costi B.W. Boehm, Software Engineering, IEEE Trans. On Computers, Percent of total cost Hardware Development 20 Software Maintenance Year

6 Cosa è l ingegneria del software? [First NATO Conference, 1968] Software engineering is the establishment and use of sound principles in order to obtain economically software that is reliable and works efficiently on real machines [IEEE Std Glossary of Software Eng. Terminology] Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software

7 Un semplice ciclo di vita problem requirements engineering Requirement s Specification design Design Program Working Program implementation testing maintenance

8 Requirements Engineering Descrivere Il problema da risolvere, E in quali condizioni Requisiti Funzionali Non-funzionali (HW, SW esterno, numero degli utenti, ) La descrizione comprende: funzionalità, estensioni future, quantità/tipo della documentazione richiesta, prestazioni e tempo di risposta Può comprendere uno studio di fattibilità

9 Design Modellare il sistema da sviluppare Moduli, componenti e interfacce Prendere delle decisioni da includere nella Architettura del Software Utile per Valutare Utilizzare come template per una famiglia di prodotti Scheletro per componenti riutilizzabili

10 Implementation Concentrarsi nei singoli moduli Restare coerenti alla architettura software Non sempre possibile nei linguaggi tradizionali Attuata dai nuovi linguaggi di programmazione Spesso facilitata dall uso di pseudocodice durante la fase di design

11 Testing Trasversale e non successivo all implementazione Soltanto a diversi livelli di astrazione Ai confini delle fasi Verifica Validazione

12 Maintenance Gestire i cambiamenti dopo la consegna Migliorativa(cambiamenti nei requisiti utente) Adattiva (cambiamenti nell ambiente) Correttiva (eliminazione degli errori) Preventiva (per una migliore mantenibilità futura del sistema)

13 Distribuzione delle risorse 10% 10% 45% specification 20% 15% requirements engineering design coding testing

14 Distribuzione delle attività di maintenance Migliorativa 50% Adattiva 25 % Correttiva 21% Preventiva 4 %

15 Il Il ciclo di vita del software

16 Semplice Ciclo di vita problem Req. engineering Requirement s Specification Design Design Program Working Program Implementation Testing Maintenance

17 Semplice Ciclo di vita Basato sui documenti Gli obiettivi sono raggiunti se i relativi documenti sono stati prodotti Per esempio: specifica dei requisiti, specifica di progetto, programma, documenti di test, Problemi I commenti alla fine di ogni fase non sono presi in considerazione La maintenance non implica evoluzione Si corregge il prodotto, ma non si torna indietro nelle fasi

18 Waterfall Model Req. engineering V & V Design V & V Pure waterfall Implementation V & V Modified waterfall Testing V & V Maintenance V & V

19 Waterfall Model (cont.) Include iterazioni e feedbacks V&V alla fine di ogni fase Verifica (stiamo costruendo il sistema correttamente?) Garantire la corrispondenza tra un prodotto software e le sue specifiche) Validazione (stiamo costruendo il prodotto corretto?) Garantire la correttezza del prodotto rispetto ai suoi obiettivi I requisiti utente devono essere stabiliti il prima possibile Problemi Troppo rigido Gli sviluppatori non si possono muovere tra i diversi livelli di astrazione

20 Motivazione Prototyping La raccolta dei requisiti è un operazione molto difficile Il Software è sviluppato perché la situazione corrente è insoddisfacente Tuttavia la situazione desiderata è ancora sconosciuta Caratteristiche Il Prototyping è usato per ottenere i requisiti di alcuni aspetti del sistema Il Prototyping dovrebbe essere un processo relativamente economico Utilizzare strumenti di sviluppo rapidi (Integrated Development Environment) Non tutte le funzionalità devono essere implementate I controlli di qualità non sono richiesti

21 Prototyping: uno strumento per la raccolta dei requisiti Req. engineering Design Design Implementation Implementation Testing Testing Not ready ready Maintenance

22 Tipi di Prototyping Throwaway prototyping: l ennesimo prototipo è seguito da un processo di sviluppo waterfall-like Evolutionary prototyping: l ennesimo prototipo rappresenta il prodotto finito

23 Vantaggi del Prototyping Il sistema risultante è di facile uso I bisogni dell utente sono coperti meglio Il sistema risultante ha meno funzionalità I problemi sono rilevati prima Il design è di migliore qualità Il sistema risultante è di più facile mantenimento Lo sviluppo richiede meno risorse

24 Svantaggi del Prototyping Il sistema risultante ha meno funzionalità Le prestazioni del sistema finale sono peggiori Il design è di qualità inferiore Il sistema finale è più difficile da mantenere L approccio basato sul prototyping richiede un team con maggiore esperienza

25 Raccomandazioni sul Prototyping Gli utenti e i progettisti devono essere consapevoli dei problemi e dei possibili rischi Utilizzare il prototyping quando i requisiti non sono chiari Il prototyping deve essere pianificato e controllato

26 Una fabbrica del Software Gli sviluppatori non sono propensi a realizzare del software facile da mantenere e da riutilizzare, comporta costi addizionali Il punto di vista cambia se l obiettivo è la realizzazione di una famiglia di prodotti e non soltanto la versione iniziale di un prodotto I mezzi di un azienda che sviluppa software sono: La conoscenza condivisa da tutti gli impiegati L insieme dei prodotti parzialmente sviluppati presenti nell azienda

27 Una fabbrica del Software (cont.) Il riuso diventa importante Quindi si parla di Component-Based Software Engineering (CBSE) Sono stati fatti progressi nell area del Design per il riuso (per esempio, architetture software e modelli di progetto) Componenti software L idea di una fabbrica del software Condividere la conoscenza Condividere prodotti e/o componenti riutilizzabili

28 Paradigma object-oriented

29 Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced by Hierarchy of functions Class hierarchy

30 Cosa sono gli oggetti? Il mondo può essere percepito Punto di vista filosofico Oggetto = astrazione di un entità reale Il mondo è fatto di oggetti Gli oggetti interni nascono e muoiono Gli oggetti esterni sono eterni Punto di vista di un modello Oggetto = Identificatore + Stato + Comportamento Stato attributi variabili Comportamento operazioni Punto di vista dell ingegneria del Software Oggetto = astrazione di un entità che contiene i dati e le operazioni Costruttore e distruttore

31 Archiettura Object-oriented Organizzazione di un sistema software in termini di una collezione strutturata di oggetti Strutturata = include associazioni di Utilizzo Aggregazione ( parte di o contiene un ) Ereditarietà ( è un ) Collezione = Gli oggetti sono indipendenti dal sistema cui appartengono, perché Sono significativi e utili individualmente Riutilizzabili per sistemi differenti

32 Classi e Oggetti Classe = descrizione di un dato astratto Offre Nome Definizione della sua struttura dati Servizi per accedere alla sua struttura dati Elemento statico Oggetto = istanza di una classe Offre Identità Stato, accessibile attraverso i servizi definiti dalla classe Elemento run time

33 Classi e Oggetti (cont.) A run time Esistono solo oggetti Nel codice sorgente Esistono solo classi

34 Instanziazione Processo per la creazione di un oggetto Gli attributi sono inizializzati L istanza è assegnata ad una variabile Operatori per l instanziazione Costruttore Distruttore Dictionary language create_dictionary() insert_word() search_word() give_next_word() D1: Dictionary language = German

35 Associazioni Relazioni tra classi e tra oggetti Cardinalità delle associazioni Numero degli oggetti partecipanti 1, 0..1, M..N, *, 0..*, 1..* Tipo di associazione Numero di classi che partecipano all associazione Binaria, ternaria, N-aria

36 Aggregazione Associazione asimmetrica Criteri che implicano l aggregazione Una classe rappresenta una parte di un altra classe Gli attributi di una classe sono propagati ad un altra classe Un azione di una classe implica un azione di un altra classe Le istanze di una classe sono subordinate alle istanze di un altra classe +owner co-owner Person Building 1..* 0..* aggregate class Car Engine 1 1

37 Permette che Ereditarietà L evoluzione del Software sia comparabile con le precedenti versioni ma non è sufficiente per garantire il riuso e l estendibilità Si realizza attraverso i meccanismi di Estensione delle classi Specializzazione delle classi Combinazione delle classi

38 Ereditarietà (cont.) superclass Object Point Polygon heir subclass Triangle Rectangle Un erede Offre i servizi dell antenato Del quale rappresenta un estensione Offrendo nuovi servizi E/O una specializzazione Sfruttando le potenzialità definite dai servizi degli antenati e ridefinendoli per il loro caso specifico (polimorfismo)

39 Unified Modeling Language

40 Motivazione Perchè una notazione unificata? Potenza espressiva Completezza Consistenza

41 Il valore dell UML È uno standard aperto Supporta l intero ciclo di sviluppo del software Supporta diverse aree di applicazione É basato sull esperienza e le necessità degli utenti È supportato da molte applicazioni

42 Motivazione (cont.) Perchè una notazione con diagrammi multipli? Obiettivo Coprire più aspetti di un sistema complesso Complessità Necessario per un analisi e un design dettagliato

43 UML Modelli, Viste e Diagrammi Un diagramma è una vista in un modello Rappresenta il sistema da una certa prospettiva Fornisce una parziale rappresentazione del sistema É semanticamente consistente con le altre viste

44 Una vista architetturale Una vista architetturale è una descrizione semplificata (un astrazione) di un sistema Da una particolare prospettiva Copre alcuni aspetti Omette quelle entità che non sono rilevanti per questa prospettiva

45 La visione del Software Architect Logical View Implementation View End-user Functionality Use Case View Programmers Software management System integrators Performance Scalability Throughput Process View Conceptual Deployment View System engineering System topology Delivery, installation Communication Physical P. Kruchten, Nov The 4+1 View Model of Architecture IEEE Software

46 Quante viste? Le viste dovrebbero riguardare lo specifico contesto Non tutti i sistemi richiedono tutte le viste Un sistema può avere bisogno di viste addizionali Data view, security view,

47 Modelli, Viste e Diagrammi Static views Sequence Diagrams Use Case Diagrams Class Diagrams Object Diagrams Collaboration Diagrams Models Component Diagrams Statechart Diagrams Dynamic views Activity Diagrams Deployment Diagrams

48 Diagrammi principali Per la struttura Class diagram Object diagram Per le interazioni Sequence diagram Collaboration diagram Per gli Aspetti dinamici State diagram Per gli Aspetti fisici Component diagram Deployment diagram

49 Alcuni Riferimenti Fowler, M., Scott, K., UML distilled Second Edition a brief guide to the standard object modeling language, Addison-Wesley, 2000 Stevens P., Pooley, R., Using UML Software Engineering with Objects and Components, Addison- Wesley, 2001 (Updated Edition to UML 1.4) The Object Management Group UML Web page, online at OMG, OMG Unified Modeling Language Specification, Version 1.4, Sep. 2001, on-line at Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, 1999.

50 Classi e Instanze di classi Class level Student ID Name matriculate() enrol 1..n 1 association Faculty Name Athenaeum open() Instance level Albert Einstein Galileo Galilei Martin L. King X X X association instances (or links) Engineering Architecture Computer Science Economics Arts

51 A quale livello appartengono i diagrammi Struttura Class diagram Object diagram Interazioni Sequence diagram Collaboration diagram Aspetti dinamici State diagram Aspetti fisici Component diagram Class level Instance level Deployment diagram Class diagram Object diagram Sequence diagram Collaboration diagram State diagram Component diagram Deployment diagram

52 Use Case Diagram

53 Analisi e Specifica dei Requisiti Attività per l analisi e la raccolta dei requisiti Studiare l ambito di un applicazione Identificare i confini e le interazioni tra l applicazione e il mondo esterno Identificazione e comprensione dei requisiti Attività per la specifica dei requisiti Specifica dei requisiti (basati su cosa e non su come) Validazione/Verifica dei requisiti specificati

54 Analisi: Metodologie Nessun metodo scientifico Linee guida, principi generali e tecniche empiriche Troppi Fattori soggettivi, Fattori umani, e Problemi di comunicazione

55 Analisi: Linee Guida L analisi dovrebbe identificare Una rappresentazione delle informazioni più significative Un modello del comportamento del software L analisi dovrebbe considerare come il sistema Sarà strutturato (dalla prospettiva utente) Fornirà le funzionalità I sistemi complessi devono essere suddivisi in modo gerarchico: L analisi è eseguita separatamente sulle differenti parti

56 Specifica: levelli di formalismo Specifica Informale Basata sul linguaggio naturale (ambiguo) Specifica Formale Basata sul linguaggio matematico Specifica mista (Semi-formale) Composta da una parte formale e una informale

57 Specifica: tipi Specifica dei dati (vista statica) Specifica del comportamento (vista dinamica)

58 Specifica: stili per il comportamento Operazionale Specifica le procedure Esempio: La lista B è ottenuta dalla lista A muovendo il più piccolo elemento di A nella prima posizione di B, il nuovo più piccolo elemento di A nella seconda posizione di B, e procedendo in questo modo finché la lista A è vuota. Descrittivo Specifica le proprietà Esempio: la lista B è una permutazione ordinata della lista A

59 Use Case Diagram Notazione semi-formale Specifica le interazioni tra il sistema e il mondo esterno Utile per Obbligare l analista ad esprimere dei confini ben definiti tra il sistema e il mondo esterno Organizzare le funzioni del sistema in elementi (use cases) sui quali focalizzare l attenzione Fornire una prima base per la specifica della struttura del sistema dal punto di vista dell utente

60 Elementi di un Use Case Diagram Actor Qualcuno (utente) o qualcosa (sistema esterno, hardware) che Scambia informazioni con il sistema Fornisce input al sistema, o riceve output dal sistema Use Case Un unità funzionale (funzionalità) parte del sistema

61 Relazioni tra Use Cases Actor Actor Use Case Use Case Interaction. Determina: Quali attori participano in un use case Dove l esecuzione inizia Use Case A <<include>> Use Case B Usage. Modella il fatto che una funzionalità selezionata è usata nel contesto di un altra funzionalità (una è la fase dell altra) Use Case A Use Case B Generalization. Definisce una funzionalità come un estensione di un altra già esistente (special case)

62 Esempio: Corsi on line All inzio del semestre la segreteria deve fornire agli studenti la lista dei corsi disponibili attraverso un sistema di registrazione on line. Ogni studente deve selezionare 4 corsi disponibili ed esprimere due possibili alternative. Ogni corso deve avere tra 3 e 20 studenti: corsi con meno di 3 studenti sono cancellati, e quelli con più di 20 sono suddivisi. All inzio i professori accedono al sistema per inserire i loro corsi nella lista, in seguito alle selezioni degli studenti loro accedono per controllare lo stato degli studenti. Dopo il periodo di selezione, il sistema crea le liste definitive, risolvendo tutte le anomalie e le manda all ufficio amministrativo che procede alla tassazione di ogni studente. Gli studenti accedono al sistema per vedere la lista dei loro corsi Tutte le interazioni utente sono autenticate

63 Esempio: Corsi on line Administrative Office Course Selection <<include>> Request Students List <<include>> Students User Authentication <<include>> <<include>> Professor Request Course List Insert Course

64 Altro esempio <<include>> Hotel Booking Check availability <<include>> Customer Acquire Customer data <<include>> Acquire Credit Card data Hotel Booking guaranteed by Credit Card

65 Class diagrams

66 Cosa è un Class Diagram Un Class Diagram descrive I tipi degli oggetti nel sistema I tipi di relazioni statiche tra di loro Disegniamo i Class Diagrams sotto tre diverse prospettive Concettuale Indipendente dal software Indipendente dal linguaggio Specificazione Focalizzati sull interfacce del software Implementazione Focalizzati sull implementazione del software

67 Class Class Name private public Window - visible - position - size + resize() + display() + hide() + move() Attributes Operations

68 Class... Sintassi degli attributi attrname : attrtype = initialvalue Sintassi delle operazioni Visibility opname (argname:argtype=defaultvalue, ):returntype <<stereotype>> ClassName publicstate : UserDef = tested privateauthor : UserDef = pam ProtectedOp(argname) : return <<Interface>> ClassInterface B <<Interface>> ClassInterface A

69 Associazioni Relazioni strutturali tra classi di oggetti Cardinalità delle associazioni 1, 0..1, M..N, *, 0..*, 1..* Tipo di relazione binaria, ternaria, N-aria

70 Notazione per la cardinalità n * m..n Esattamente n Zero o più Tra m e n (inclusi) m..* 0..1 Da m in su Zero o uno (opzionale)

71 Associazioni binarie Appello -data -materia -elencostudenti +stampa() +prenotastudente() * Si-svolge-il 4 1 Molteplicità DataAppello -giorno -mese -anno +stampa() Studente -nome -cognome -matricola +stampa() Nome della relazione frequenta 4 * +frequentante +frequentato Corso -materia -docente +stampa() Ruoli

72 Use Association Due classi sono in USE association (B usa A) se le istanze di B possono mandare messaggi alle istanze di A Un oggetto usa un altro oggetto se è capace di mandargli dei messaggi +Employer +Candidate Company hiring Person +apply() -planinterviews() * +interview() +seekjob()

73 Nomi nelle associazioni User Profile user Information 1 1 User 1 user service information Subscription 0..* 0..* Service Profile +userpreferences 0..* 0..* subscription constraints registration Terminal -Address +Type 1..* 1..* supports default 1..* 0..* Service +startservice() 1

74 Aggregation Modellare il sistema di prenotazione agli appelli dei corsi. Ogni appello include una data composta da giorno, mese, anno, ed è associato ad un corso. Dietro richiesta, si può iscrivere all appello uno studente. Il sistema permette inoltre di Spostare la data dell appello Stampare le informazioni di ogni oggetto

75 Aggregation Appello - listaprenotati - aula * * 1 Data Appello -giorno -mese -anno +stampa() +gestioneprenotaz() +sposta() +stampa() +cambiastato() * 1 * Studente -nome -cognome -matricola +stampa() +iscrivi() Corso -materia -docente +stampa()

76 Generalization Relazione di classificazione tra un elemento generale e un elemento più specifico Ereditarietà nella programmazione ad oggetti Construire una classe da un altra Codividere attributi, operazioni e vincoli

77 Specializzazione pura Window Base class (superclass) -title -position -size +resize() +move() +close() Generalization association Text Window -text Derived classes (subclasses) Image Window -image inherits from derives from is a +replacetext() +deletetext() +refresh()

78 Esempio: Gerarchia di classi Costruire le associazioni di ereditarietà tra i seguenti oggetti: Esseri Viventi Esseri Umani Fiori Animali Vegetali Commerciante Fioraio Cliente Suggerimento Raggruppare gli elementi in insiemi di classificazione e in seguito costruire la gerarchia di generalizzazione

79 Esempio: Gerarchia di classi Essere Vivente Animale Vegetale Essere Umano Fiore Commerciante Cliente Fioraio

80 Specializzazione inpura Vogliamo definire eccezioni al meccanismo della specializzazione Overriding Modificare proprietà ereditate Di solito per l implementazione di operazioni (metodi)

81 Overriding Person -name -surname +print() Employee -qualification -salary -ID Student +print() +print()

82 Ereditarietà multipla Una classe deriva da una serie di superclassi Non tutti i linguaggi di programmazione la supportano

83 Quando si usano i Class Diagrams Si usano sempre Sono alla base di tutti i metodi Object Oriented Sono alla base per i generatori di codice La prospettiva di riferimento è Modello concettuale durante la raccolta dei requisiti Modello di specifica durante il design Modelli di implementazioni per linguaggi specifici

84 Quando si usano i Class Diagrams(cont.) Non disegnare modelli per qualsiasi cosa Focalizzarsi sugli aspetti principali Non specificare troppi dettagli in una fase prematura

85 Object Diagrams

86 Object Diagrams Un object diagram mostra le istanze delle classi e i collegamenti tra di loro Un object diagram è un istantanea degli oggetti nel sistema In uno specifico momento Con uno specifico obiettivo Interazioni Sequence Diagram Scambio di messaggi Collaboration diagram Operazioni Deployment diagram

87 Un Oggetto M1: Menu window ID label : Class Name visible=true position=(10,23) size=160 Attribute values

88 Oggetti e collegamenti

89 Interazioni tra oggetti Un oggetto interagisce con un altro oggetto inviando un messaggio: per esempio, una richiesta per eseguire un operazione + una serie di parametri La ricezione del messaggio causa la selezione e l esecuzione dell operazione Regola base Delegare ad altri oggetti le operazioni che essi sono capaci di compiere Risultati Buon disaccoppiamento tra oggetti Semplicità Riutilizzo

90 Esempio: registrazione per un esame stampa Jan: Appello data materia elencostudenti stampa stampa D1:DataAppello giorno mese anno 1: Studente stampa nome N-1:Studente cognome N Studente nome matricola cognome matricola cognome matricola SoftEng: Corso nome codice

91 Interazioni tra oggetti

92 Specifica del comportamento 1)Si analizzano e descrivono gli scenari principali delle operazioni del sistema Sequence diagrams Viste parziali 2)Ci si concentra in ogni classe e si specifica il suo comportamento Tutti i coportamenti previsti e quelli critici

93 Diagrammi di interazione Sono diagrammi semi-formali che descrivono scenari di esempio per le operazioni del sistema, in termini di Oggetti e attori Messaggi scambiati e in quale ordine temporale (sequenza) Si suddividono in Sequence Diagrams Collaboration Diagrams Non sono sempre sufficienti per tenere in considerazione tutti i possibili comportamenti

94 Sequence Diagrams

95 Actor (*) Sequence Diagram Instantiated class Object : Professor :course options form :course form :course co1:course offering 1: add a course Sequence number 2: display 3: select course offering 4: add professor (professor id) 5: get professor (professor id) lifeline 6: add professor (professor) (*) Dagli Use Case Diagrams per modellare le entità esterne

96 Sequence Diagram (cont.) Modi di utilizzo Documentazione degli use cases Più vicini all utente Non molto dettagliati Frecce: eventi che possono accadere Nessuna differenza tra flusso di controllo e flusso dati Strumento di sviluppo Rappresentazione accurata delle interazioni tra gli oggetti Frecce: messaggi trasmessi Chiamate di procedure, eventi discreti, segnali Sincroni o asincroni

97 Formato dei messaggi Cancella Ritorno implicito esplicito Ricorsione X :A :B :C 1: Sync 2: Activate 3: Asynch Vincoli temporali {t -t < 2s} 4: Reflexive Pseudo-codice while x loop Condizioni di iterazione (direttamente nel messaggio) *[X]

98 Esempio: generatore di allarmi Specificare il comportamento a livello classe, per il seguente sistema Un sistema di allarme basato su un sensore genera eventi Mostra l allarme sul pannello di controllo (visibile all utente) Attiva un trasmettitore acustico Manda un segnale al servizio di monitoraggio

99 Soluzione : Sensor : Event : Control Panel : User : Acoustic Transmitter : Monitoring Service display display ring signal

100 Esempio: configurazione dell utente : User define password "Type password now" [password] : Control Panel : System : Sensor "Retype password" [password] set password configure Sensors (N) set Data get Next Sensor [ref] [sensor ID, Tel. Number] while N loop set Data

101 Collaboration Diagrams

102 Collaboration Diagrams Descrive le interazioni tra oggetti, vengono espressi Il contesto per un gruppo di oggetti (oggetti e collegamenti) L interazione tra gli oggetti 1: Go up 2 : Elevator 3: Close : Cabin : Door 2: Turn on : Light

103 Esempio: generatore di allarmi 2: display : Control Panel 3: display : Sensor 1: 9: : Event 4: 5: ring : User 6: 8: 7: signal : Acoustic Transmitter : Monitoring Service

104 Confronto Sequence diagrams Enfasi sulla sequenza Collaboration diagrams Enfasi sui collegamenti statici tra gli oggetti Entrambi Semplicità e Comunicazione Non adatti a modellare le possibili scelte alternative

105 Si Quando usare i diagrammi di interazione Per analizzare il comportamento di oggetti multipli in un use case comune Per mostrare la collaborazione tra oggetti No Per fornire un esatta descrizione delle interazioni Per analizzare il comportamento di un singolo oggetto in use cases multipli State diagram Per analizzare il comportamento su use case o flussi di esecuzione multipli Activity diagram