Top Banner
Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory Activity Diagrams Activity Diagrams (lezione 3) (lezione 3) Antonino Sabetta [email protected]
86

Activity Diagrams (lezione 3)labsewiki.isti.cnr.it/_media/projects/corsi/umlcnr2009/...actions coordinated by activity models can be initiated because other actions finish executing,

Feb 04, 2021

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo”Software Engineering Laboratory

    Activity DiagramsActivity Diagrams(lezione 3)(lezione 3)

    Antonino Sabetta

    [email protected]

  • SOFTWARE ENGINEERING LABORATORY

    Una vista d'insieme

    » introduzione alla modellazione con UML» le viste di UML

    » use case view» logical view » implementation view » process view » deployment view

    » RUP : un possibile processo di sviluppo» I due usi di UML

    » Documentare, capire, comunicare» Automatizzare lo sviluppo (UML non è solo “figure”)

  • SOFTWARE ENGINEERING LABORATORY

    structure diagrams

    » class diagram» object diagram» component diagram» deployment diagram» composite structure diagram» package diagram

  • SOFTWARE ENGINEERING LABORATORY

    behavior diagram

    » state machine diagram» activity diagram» use case diagram» interaction diagrams

    » sequence diagram» communication diagram» interaction overview diagram» timing diagram

  • SOFTWARE ENGINEERING LABORATORY

    Dalle puntate precedenti...

    » Casi d'uso:» Identificano gli scenari di interazione tra

    attori e il sistema» Goal-oriented: il punto di vista è “esterno”

    (cosa il sistema fa per l'attore, senza descrivere i meccanismi interni)

    » Realizzazione dei casi d'uso:» Relazione tra un caso d'uso e la sua

    “implementazione” (descrizione dei meccanismi che consentono al sistema di offrire la funzionalità che interessa all'attore)

  • SOFTWARE ENGINEERING LABORATORY

    Casi d'uso, interazioni, scenari

  • SOFTWARE ENGINEERING LABORATORY

    In questa lezione e nella successiva...

    » Una notazione per descrivere:» interazioni (tra attore e sistema) che

    realizzano un caso d'uso» funzionamento interno del sistema (per

    descrivere funzionalità offerte dal sistema per quel caso d'uso)

    » Tra l'analisi e il design:» Percorso dalla descrizione “dall'esterno” (dal

    punto di vista di chi deve usare il sistema) “all'interno” (vista di chi deve realizzare il sistema)

  • SOFTWARE ENGINEERING LABORATORY

    In questa lezione e nella successiva...

    » Activity Diagram» Enfasi sui passi necessari a realizzare un

    caso d'uso o una operazione del sistema» Sequence Diagram

    » Enfasi sulla sequenza delle interazioni tra attore e sistema, e tra le diverse parti del sistema

  • SOFTWARE ENGINEERING LABORATORY

    Activity Diagram: introduzione

    » Modellazione del comportamento» Enfasi sulla sequenza di azioni che

    vengono svolte come realizzazione di un behaviour» non su chi le svolge

    » Sequenza determinata in termini di» control flow» object flow

  • SOFTWARE ENGINEERING LABORATORY

    Activity Diagram: introduzione

    Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models. The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because events occur external to the flow.

    (UML 2 Superstructure)

  • SOFTWARE ENGINEERING LABORATORY

    Caratteristiche principali

    » Adatti a:» Rappresentare comportamenti complessi» Rappresentare parallelismo

    » Modulari» È possibile strutturare comportamenti

    complessi» Intuitivi

  • SOFTWARE ENGINEERING LABORATORY

    Esempi di applicazioni

    » realizzazione di uno use-case» modellare un workflow (in senso lato)» modellare le azioni compiute quando una

    operazione viene eseguita (sequenza di step)» modellare il comportamento di un oggetto» descrivere come un insieme di azioni

    influisce su un insieme di oggetti (come ne cambia lo stato)

    » Descrivere un algoritmo

  • SOFTWARE ENGINEERING LABORATORY

    Outline

    » Concetti di base» Attività, azioni, token, oggetti, segnali» Controllo di flusso, parallelismo» Notazione essenziale

    » Costrutti avanzati» Behaviour strutturati» Eccezioni» Swimlane» Expansion region

  • SOFTWARE ENGINEERING LABORATORY

    Concetti di base - 1

    » Activity: contiene azioni e/o altre attività

    » Action: azione elementare» Control flow: stabilisce la sequenza

    secondo cui le azioni di un'attività vengono svolte

    » Object flow: modella il fatto che un'azione può avvenire quando il suo input (prodotto in output da un'altra azione) diventa disponibile

  • SOFTWARE ENGINEERING LABORATORY

    Concetti di base - 2

    » Control node:» Initial» Activity final» Flow final» Decision/Merge – costrutti condizionali» Fork/Join – behaviour paralleli» … altri elementi avanzati (vedi seguito)

    » Connettori» Eccezioni» Segnali» Swimlane

  • SOFTWARE ENGINEERING LABORATORY

    Notazione essenziale

  • SOFTWARE ENGINEERING LABORATORY

    Control flow e data flow

    » Control flow

    » Data flow (object flow)

  • SOFTWARE ENGINEERING LABORATORY

    Notazione di base - 2

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example (rejected)-

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example (accepted) -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram – example -

  • SOFTWARE ENGINEERING LABORATORY

    Decision node (branch-merge) – 1

  • SOFTWARE ENGINEERING LABORATORY

    Decision node (branch-merge) - esempio

  • SOFTWARE ENGINEERING LABORATORY

    Parallelismo – costrutto Fork/join

    Fork Join

    » Il token viene “replicato” dal nodo Fork (tante repliche quanti sono le frecce che partono dal Fork)

    » I token in arrivo vengono “fusi” dal nodo join (ma solo quando tutte le frecce entranti hanno un token pronto!)

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Fork-join

  • SOFTWARE ENGINEERING LABORATORY

    Nodi finali

    » L'attività si conclude non appena un token raggiunge un nodo “activity-final”

    » Il nodo flow-final distrugge il token, ma non necessariamente termina l'attività

  • SOFTWARE ENGINEERING LABORATORY

    Esempio

    Nota: che succede se questa azione ci mettetroppo tempo a terminare?

  • SOFTWARE ENGINEERING LABORATORY

    Segnali

    » Invio/ricezione di segnali» Avvengono istantaneamente (a differenza

    delle azioni, che possono impiegare del tempo)

    » L'azione “ricezione di segnali” è attiva non appena si attiva l'attività in cui essa è contenuta

    » Segnale temporizzato

  • SOFTWARE ENGINEERING LABORATORY

    Partizioni (swimlane) (1)

  • SOFTWARE ENGINEERING LABORATORY

    Partizioni (swimlane) (2)

  • SOFTWARE ENGINEERING LABORATORY

    Pin – parametri di ingresso/uscita

  • SOFTWARE ENGINEERING LABORATORY

    interruptible region - esempio

  • SOFTWARE ENGINEERING LABORATORY

    Connettori

  • SOFTWARE ENGINEERING LABORATORY

    Eccezioni

    Dopo un'eccezione,l'esecuzione riprende da qui

  • SOFTWARE ENGINEERING LABORATORY

    Esempio - swimlane

  • SOFTWARE ENGINEERING LABORATORY

    Esempio – swimlane ortogonali

  • SOFTWARE ENGINEERING LABORATORY

    Esempio - Sistema di bug-report» L'utente segnala un problema» Si cerca di riprodurre il problema» A) ci si riesce:

    » (*) Si identifica la causa del problema e si formula una soluzione

    » (**) Si prova la soluzione » Se la soluzione non funziona si torna a (*)» Se la soluzione funziona:

    » (***) In parallelo:» Si registra la soluzione (il report viene chiuso)» Comunicazione a chi aveva segnalato il problema

    » B) non ci si riesce:

  • SOFTWARE ENGINEERING LABORATORY

    Esempio - Sistema di bug-report

    » L'utente segnala un problema» Si cerca di riprodurre il problema» A) ci si riesce

    » ....» B) non ci si riesce:

    » Si corregge la formulazione del problema» Si riparte da (*)

    » Se in (*) si riesce a riprodurre il problema, ma questo è stato già segnalato: si va a (**)

  • SOFTWARE ENGINEERING LABORATORY

    Esempio - Sistema di bug-report

    » Se in (*) si riesce a riprodurre il problema, ma questo è stato già segnalato ed esiste già una soluzione: si va a (***)

    » Nota: la specifica testuale (anche di procedimenti semplici come questo) può essere difficile da seguire....

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    activity diagram - example -

  • SOFTWARE ENGINEERING LABORATORY

    Tirando le somme...

    » Descrizione testuale difficile da seguire» Presta il fianco ad errori concettuali difficili

    da scovare

    » Rappresentazione grafica rende evidenti relazioni “causali” tra azioni

    » Permette di strutturare il procedimento, suddividendo il problema di modellazione in problemi più piccoli

  • SOFTWARE ENGINEERING LABORATORY

    Sommario e conclusione

    » Passaggio da un modello “dall'esterno” (cosa il sistema fa) ad un modello descrive i passi che realizzano uno scenario (interazione attore/sistema) o una funzionalità del sistema

    » Activity diagram:» una notazione intuitiva ma potente» permette di esprimere alternative,

    parallelismo, comportamenti strutturati» enfatizza concatenazione di azioni

    Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 49Slide 50Slide 51Slide 52Slide 53Slide 54Slide 55Slide 56Slide 57Slide 58Slide 59Slide 60Slide 61Slide 62Slide 63Slide 64Slide 65Slide 66Slide 67Slide 68Slide 69Slide 70Slide 71Slide 72Slide 73Slide 74Slide 75Slide 76Slide 77Slide 78Slide 79Slide 80Slide 81Slide 82Slide 83Slide 84Slide 85Slide 86