Università degli Studi di Parma - cs.unipr.it · 1 UML nella progettazione SW - 1 Giulio Destri -...
Transcript of Università degli Studi di Parma - cs.unipr.it · 1 UML nella progettazione SW - 1 Giulio Destri -...
1
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 11
Giulio Destri
UML nella progettazione software
Università degli Studi di ParmaFacoltà di Scienze MM. FF. NN.
Corso di Laurea in Informatica
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 22
Scopo del modulo
Introdurre
L’uso di UML per l’analisi e la progettazione software, nel
contesto dei sistemi informativi delle aziende
2
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 33
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 44
Argomenti
• L’inizio di ogni progetto: la modellazione
• Le specifiche utente• Object orientation per la
modellizzazione• UML come linguaggio per descrivere i la
realtà, anche in vista della realizzazione di sistemi IT
3
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 55
Come si parte
• Un progetto deve partire dalla buona conoscenza della realtà
• Si deve conoscere dove si è
• Si deve sapere dove si vuole arrivare
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 66
Impatti degli errori
Analisi
Specifiche Test/produzione
Sviluppo
Un errore nelle specifiche aumenta il proprio impattonelle fasi successive
4
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 77
Necessità del modeling
• E’ necessario modellizzare la realta
• Un modello è una semplificazione della realtà che si ottiene– Riducendo le caratteristiche in esame– Considerando solo quelle utili al fine del
progetto considerato/analisi in corso
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 88
Un sistema
• Un sistema è un insieme di elementi in relazione fra di loro secondo leggi ben precise, che concorrono al raggiungimento di un obiettivo comune
• Sistemi naturali• Sistemi artificiali• Sistemi misti
5
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 99
Un sistema generico
Osservatore
Sistema
Ingresso
Uscita
Modello a “scatola nera” (black-box)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1010
Un modello di un sistema
• E’ una rappresentazione del sistema stesso che, pur avendo forma e natura diverse da esso, ne conserva ed evidenzia in modo analogico alcune caratteristiche particolarmente significative per l’analisi
6
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1111
Un sistema con stato interno
Osservatore
Sistema
Ingresso
Uscita
Modello con stato interno
Variabili Di
Stato interno
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1212
Un sistema IT generico
Utente
Sistema IT
Richiesta
Risposta
All’interno del sistema un certo processo genera larisposta alla richiesta
7
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1313
Un processo
• Ogni sistema è caratterizzato da uno stato
• Il processo è la successione di stati attraverso cui un sistema passa nel corso della sua evoluzione
• Da cui deriva anche l’uso del termine processo per indicare un programma in esecuzione
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1414
I modelli
• ci aiutano a “visualizzare” un sistema come è o come vorremmo che fosse
• ci permettono di specificare la struttura o il comportamento di un sistema
• ci forniscono un “template” che ci guida nella costruzione di un sistema
• documentano le decisioni che abbiamo preso
8
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1515
Arrivare ai modelli
• Definire l’obiettivo• Identificare il sistema e le parti
interessanti• Definire i vincoli• Generare un modello di massima• Formalizzare completamente il sistema• Usare il modello (es. simulazione)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1616
I sistemi sono suddivisibili in componenti
SistemaSistema
9
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1717
Per un sistema non banale
• non un solo modello
• ma un piccolo insieme di modelli, – che possono essere costruiti e studiati
separatamente, – ma che sono strettamente interrelati
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1818
Identificazione dei componenti
Ruoli
Dottore
Insegnante
SistemaSistemaCose Tangibili
Aereo
Auto
Computer
Avvenimenti
RitiroMeeting
Interazioni
Intervista
Accordo
10
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 1919
Attenzione alla complessità
• La mente umana può elaborare 7 più o meno 2 cose contemporaneamente
• Se il modello non è ben fatto– Troppi dettagli – alcuni sfuggono– Pochi dettagli – mancanza di conoscenza
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2020
Approcci all’analisi
• Top-down: scomposizione di un sistema per passi successivi in sottosistemi sempre più elementari
• Bottom-up: costruzione di un sistema complesso per composizione successiva di sistemi elementari
11
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2121
Ci vuole il modello giusto
• Il modello deve essere valido per il contesto in cui si opera
• Deve essere adattato all’interlocutore del momento
• Vanno presi in considerazione aspetti diversi in momenti diversi e a diversi livelli di dettaglio
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2222
Esempio: l’architetto
• D: “ho bisogno di una casa”• R: “quante prese elettriche vuole in
cucina?”
• D: “ho bisogno di una casa”• R: “di che tipo?”• D: “luminosa, spaziosa, sicura,
funzionale, …”
12
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2323
Obiettivo: specifiche utente
• Lo scopo è giungere a specifiche utente chiare
• che possano essere tradotte per passi successivi
• in strumenti hardware e software
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2424
Il riuso delle soluzioni
• Esempio del passare il fiume• Soluzioni:
– Ponte (di cemento, ferro, barche)– Traghetto– Guado– Caronte– Volare– A nuoto– ?
13
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2525
OO per la modellazione
L’approccio Object-Oriented (OO) aiuta ad individuare
• Le componenti dei sistemi• Il loro limite esatto• Le azioni svolte da ciascuna
componente• Le relazioni fra le varie componenti
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2626
Gli strumenti di modellazione
• Sono (e devono rimanere) un ausilio per la modellazione
• Devono essere finalizzati ad una maggiore comprensione di un sistema
• Non devono dare adito a metodologie rigide ma ad una maggiore flessibilità
14
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2727
Modellazione: scomporre un sistema
• Non esiste un approccio generale, ma lo scopo per cui stiamo lavorando ci deve guidare
• La granularità della scomposizione dipende dal problema e da dove si vuole arrivare
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2828
Granularità per la scomposizione di un sistema
• Dati entità, sottosistemi, sistemi…
• Una singola entità, osservata da un certo punto di vista, entro il contesto di un problema, può essere un intero sistema quando è collocato entro un altro
15
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 2929
Granularità per la scomposizione di un sistema - 2
Azienda
Applicazione
Programma
Visibilità
GranularitàMetodo
Componente
Servizio
Aderenza al business
Piccola Grande
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3030
Granularità per la scomposizione di un sistema - 3
Client
Sistemadi integrazione
sottosistemi
16
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3131
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3232
Il sistema informativo: definizione
“L’insieme di persone, apparecchiature, procedure aziendali il cui compito èquello di produrre le informazioni che servono per operare nell’impresa e gestirla”. (M. De Marco)
Corrisponde all’inglese “Information System”
17
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3333
I sistemi informativi: composizione
Pertanto un sistema informativo si suddivide in:
• Risorse umane (con organizzazione, ruoli, esperienze, ecc…)
• Risorse tecnologiche (sistema informatico, inglese “IT System”)
• Risorse organizzative (procedure, regolamenti, workflow, ecc…)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3434
Un sistema informativo è un sistema
Anche il sistema informativo• è un insieme di elementi • in relazione fra di loro • secondo leggi ben precise
• che concorrono (quasi sempre) al raggiungimento di un obiettivo comune
18
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3535
Un sistema informativo è un sistema (2)
Pertanto • non è corretto considerare solo gli
aspetti tecnologici di un sistema informativo
ma va considerato nel suo insieme
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3636
Sistemi informativi e tecnologia
• La risorsa tecnologica è comunque un componente fondamentale per tutto il sistema informativo
• Sono possibili diversi “pattern di interazione” per il rapporto tra il sistema informativo e la tecnologia, e la conseguente evoluzione del primo
19
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3737
Sistemi informativi: evoluzione
• Technological imperative: una nuova disponibilità IT “impone” il cambiamento
• Organizational imperative: nuove necessità organizzative impongono il cambiamento
• Emergent perspective: l’interazione con una nuova tecnologia conduce al cambiamento
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3838
Il sistema informatico: suddivisione
• Informatica utente (postazioni client, suite Office, e-mail, applicativi client)
• Applicativi aziendali (ERP, business intelligence, supporti progetto ecc…)
• Basi di dati (DB relazionali, archivi destrutturati ecc…)
20
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 3939
Il sistema informatico: suddivisione (2)
• Sistemi gestione accessi (es. LDAP, RACF …)
• Sistemi operativi
• Infrastrutture di rete
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4040
Un esempio di sistema informatico
Ethernet
RouterSede 1
Router
Ethernet
Sede 2
SQL*NetDCOM
Windows Terminaltn5250
TCP/IP
Oracle suUnix
AS/400
Win 2000Domain Server
Win 2000File Server Win 2000
TerminalServer
Win 2000File Server
21
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4141
Il sistema informatico: evoluzione
• Spesso nuovi applicativi• realizzati per rispondere alle mutate
esigenze del business aziendale
• devono integrarsi con applicazioni ancora efficienti
• la cui architettura è però ormai datata
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4242
Il sistema informatico: evoluzione
si ha quindi la convivenza di applicazioni
realizzate in epoche differenti su piattaforme molto eterogenee
Che devono collaborare (e quindi comunicare fra loro)
22
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4343
Problema: spaghetti-integration
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4444
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
23
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4545
UML
• Unified Modeling Language• Linguaggio unificato per la modellazione
di concetti, entità, funzionalità, processi e relazioni che fra essi intercorrono
• Nasce nel 1997• Unisce precedenti sintassi di
modellazione (Booch, OMT, OOSE)• Standard gestito dal consorzio OMG
(http://www.omg.org)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4646
UML come strumento di modellazione
Il linguaggio UML serve a descrivere, in modo grafico e “compatto”
• I requisiti utente (use case)• Le componenti dei sistemi • I dati in esse contenuti• Le azioni da esse svolte• Le relazioni che fra loro intercorrono (il
processo in cui esse operano)
24
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4747
Evoluzione di UML
• Dopo il 1997 le estensioni standard di UML si susseguono
• Anche l’uso viene esteso alle varie fasi di realizzazione dei sistemi IT
• Attualmente il riferimento è lo standard 1.5 (molti strumenti usano ancora l’1.3)
• E’ in corso di preparazione lo standard 2.0
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4848
Obiettivo di UML
• Linguaggio di modellazione, semigrafico, utilizzabile da tecnici, da non tecnici e dalle macchine
• Un modello è una semplificazione della realtà che si ottiene– Riducendo le caratteristiche in esame– Considerando solo quelle utili al fine
dell’analisi in corso
• Potenza espressiva nella documentazione
25
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 4949
L’evoluzione logica di UML
• Nella catena di produzione dei sistemi IT, l’accento viene posto sempre piùsulle fasi di analisi e progettazione
• Una fase di analisi deve provvedere la conoscenza di dove si è (AS IS) e dove si vuole andare (TO BE)Uso di UML anche nel Business Modeling
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5050
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
26
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5151
Uso di UML: IT
• Interazione con l’utente– Per rendere precise le descrizioni (Use
Cases)– Per aiutare l’utente a chiarire le proprie
necessità
• Ausilio, guida e documentazione nelle fasi di sviluppo
• Memoria storica dello sviluppo e del sistema realizzato
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5252
Uso di UML: IT e Business Modeling
• Il sistema informativo è l’insieme delle risorse umane, materiali, organizzative (regole) che gestisce e distribuisce le informazioni entro l’azienda
• Il sistema informatico è l’insieme degli strumenti IT di un sistema informativo
• Serve un linguaggio chiaro comune a tutti i componenti del sistema informativo
27
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5353
Uso di UML: Business Modeling
• Usare le stesse notazioni di UML per– Esprimere i concetti del business– Per uso diretto (per uso di analisi business) – Per uso indiretto (in vista di una successiva
implementazione di sistemi IT di ausilio al business)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5454
Uso di UML: Business Modeling
• Usare UML in tutto il sistema informativo, come linguaggio comune
• Il processo di sviluppo software usa lo stesso linguaggio sin dalle prime fasi dell’analisi
• Comunicazione con fornitori IT con linguaggio comune
28
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5555
Uso di UML: Business Modeling
• Metodologie unificate – RUP (Rational Unified Process) di Rational
(http://www.rational.com)– Scuola scandinava (Eriksson e Penker)
(http://www.opentraining.com)
• Sistemi IT “full-object”– Zucchetti
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5656
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
29
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5757
Tipi di diagrammi UML: analisi
• dei casi d’uso - Use Case Diagram• delle classi - Class Diagram• degli oggetti – Object Diagram• di sequenza - Sequence Diagram• di collaborazione - Collaboration
Diagram• di transizione di stato - Statechart
Diagram• delle attività - Activity Diagram
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5858
Tipi di diagrammi UML: implementazione
• dei componenti - Component Diagram• di distribuzione - Deployment
Diagram
30
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 5959
L’uso dei diagrammi UML: analisi
• Use Case Diagram: per capire nei dettagli “cosa” il sistema deve fare
• Class/Object Diagram: per definire le entitàfondamentali
• Activity/Statechart Diagram: per definire i processi fondamentali (fortemente “imparentati” con gli Use Case Diagram)
• Collaboration Diagram: per definire le interazioni fra le entità fondamentali
• Sequence Diagram: per definire la sequenza delle interazioni fra entità
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6060
L’uso dei diagrammi UML: implementazione
• Component Diagram: per definire nei dettagli quali parti compongono il sistema/prodotto software finito e le loro relazioni
• Deployment Diagram: per definire dove le varie parti di un programma devono essere poste in un’architettura distribuita (es. client-server)
31
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6161
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6262
Lo Use Case (caso d’uso)
• Lo use case è un contratto• Descrive l’interazione fra due entità che
interagiscono fra loro• Consente di stabilire :
– Servizi forniti– Servizi richiesti– Utenti abilitati– Vincoli nell’erogazione
32
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6363
Lo Use Case (caso d’uso)
• Il primo scopo è quello di trovare un confine preciso (boundary) per il sistema/sottosistema/componente che si sta analizzando
• Una volta definito il confine si puòstabilire
• cosa fa il sistema rispetto all’esterno
• e identificare attori e use case
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6464
Use Case Diagram: sintassi
Attore
Use CaseRelazione diinterazione
Nome del caso di uso
SistemaConfine del
Sistema (opzionale)
33
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6565
Definizione formale di uno Use Case
SEQUENZA DI TRANSAZIONI,
eseguita da un ATTORE
in interazione col SISTEMA,
la quale fornisce
un VALORE MISURABILE
per l’attore
Definisce le richieste al sistema dipendenti dall’attore
Definisce le richieste al sistema dipendenti dall’attore
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6666
Definizione pratica di Use Case
• Sequenza di transazioni in dialogo col sistema
• Comporta Sempre uno o più Attori
• Rappresenta COSA (non come) il sistema offre all’attore
• Mappato alle attività di business
Gli Use case definiscono fabbisogni di sistema “testabili” con una vista “fuori-dentro”
Gli Use case definiscono fabbisogni di sistema “testabili” con una vista “fuori-dentro”
Nome Use Case
34
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6767
Cos’è un attore
• Un attore rappresenta un’entità esterna al sistema (una persona, un altro sistema software, un componente hardware) che interagisce col sistema
• Un attore individua un ruolo piuttosto che un’entità fisica
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6868
Cos’è uno Use Case (caso d’uso)
• Uno use case rappresenta una situazione tipica di utilizzo del sistema e comprende in sé vari flussi possibili di esecuzione
• Uno use case rappresenta un’importante parte di funzionalità, completa dall’inizio alla fine
35
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 6969
Come si trova un attore?
• Un attore è un ruolo• Usare le domande:
– chi ha bisogno del sistema? (il caro vecchio: cui prodest?)
– chi userà le funzionalità principali?– chi dovrà manutenere e amministrare il sistema?– di quali dispositivi hardware il sistema ha bisogno?– con quali altri sistemi il sistema dovrà comunicare?
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7070
Come si trova uno use case?
Per ognuno degli attori precedentemente identificati, si può rispondere alle seguenti domande:
• quali funzioni l’attore richiede al sistema?• l’attore ha bisogno di leggere o scrivere o
immagazzinare informazioni nel sistema?• l’attore deve ricevere notifiche di eventi dal
sistema?
36
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7171
Attori e Use Case
• Attori e use case sono sempre collegati fra loro
• un attore isolato non può interagire col sistema
• uno use case isolato non fornisce alcuna funzionalità all’esterno (stiamo parlando di funzionalità che abbiano un senso all’esterno)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7272
Attori e Use Case - 2
Un attore può essere• attivo, ovvero inizia uno use case• passivo, ovvero partecipa a uno use
case, ma non lo inizia
37
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7373
Perché usare gli Use Case?
PER EVITARE :– Utente: non è ciò che volevo !– Analista: ma come, fa tutto quello
che mi hai chiesto...– Utente: si, ma non come
intendevo !
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7474
Use Case Diagram: esempio
Utente delBancomat
Prelievo
Compie
Caso di uso: interazioni con il bancomat
RichiestaEstratto conto
Compie
38
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7575
Descrizioni Use Case: Specificano i Dettagli
Utente delBancomat
Prelievo
Compie
Caso di uso: interazioni con il bancomat
RichiestaEstratto conto
CompieUse Case: Prelievo ContantiQuando il cliente inserisce la carta, la macchina legge il codice della stessa e controlla se è valida.
Se valida, chiede al cliente un codice PIN (4 cifre).
Se non valida, la rifiuta e la espelle.
Al ricevimento del codice PIN la macchina controlla se il PIN è corretto per la specifica carta.
Se lo è, la macchina chiede al cliente quali transazioni vuole eseguire.
Quando il cliente sceglie “Ritiro Contanti” la macchina richiede l’importo.
Sono ammessi solo multipli di 50 Euro ...
Use Case: Prelievo ContantiQuando il cliente inserisce la carta, la macchina legge il codice della stessa e controlla se è valida.
Se valida, chiede al cliente un codice PIN (4 cifre).
Se non valida, la rifiuta e la espelle.
Al ricevimento del codice PIN la macchina controlla se il PIN è corretto per la specifica carta.
Se lo è, la macchina chiede al cliente quali transazioni vuole eseguire.
Quando il cliente sceglie “Ritiro Contanti” la macchina richiede l’importo.
Sono ammessi solo multipli di 50 Euro ...
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7676
Use Case Diagram e Interfacce Utente
Utente delBancomat
Prelievo
Compie RichiestaEstratto conto
CompieUse Case: Prelievo ContantiQuando il cliente inserisce la carta, la macchina legge il codice della stessa e controlla se è valida.
Se valida, chiede al cliente un codice PIN (4 cifre).
Se non valida, la rifiuta e la espelle.
Al ricevimento del codice PIN la macchina controlla se il PIN è corretto per la specifica carta.
Se lo è, la macchina chiede al cliente quali transazioni vuole eseguire.
Quando il cliente sceglie “Ritiro Contanti” la macchina richiede l’importo.
Sono ammessi solo multipli di 50 Euro ...
Use Case: Prelievo ContantiQuando il cliente inserisce la carta, la macchina legge il codice della stessa e controlla se è valida.
Se valida, chiede al cliente un codice PIN (4 cifre).
Se non valida, la rifiuta e la espelle.
Al ricevimento del codice PIN la macchina controlla se il PIN è corretto per la specifica carta.
Se lo è, la macchina chiede al cliente quali transazioni vuole eseguire.
Quando il cliente sceglie “Ritiro Contanti” la macchina richiede l’importo.
Sono ammessi solo multipli di 50 Euro ...Da uno Use Case può derivareuna Interfaccia utente
39
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7777
Use Case Diagram: scomposizione
Utente delBancomat
Prelievo
Compie
Caso di uso: interazioni con il bancomat
RichiestaEstratto conto
Autenticazione
Compie Usa
Usa
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7878
Modello dei rapportitra Attori e Use Case
Utente delBancomat
Prelievo
CompieRichiesta
Estratto conto
Autenticazione
Compie Usa
Usa
Attori rappresentati da una personaUse case = ellissi
Astrazione delle interazioni tra Attori ed uno use caseIl sistema è circondato dal riquadro
40
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 7979
Esempio di Use Case: la cassa
acquistare articoli
log in cassierecliente
rimborsare articoli venduti
attore: un utilizzatore del sistema
caso d'uso: un "modo" di utilizzare il sistema
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8080
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
41
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8181
Gli oggetti
• Gli oggetti sono proiezioni delle entità del mondo reale (del dominio del problema) entro il dominio dell’applicazione software
• Possono essere usati anche come strumenti di modellizzazione per l’approccio OO
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8282
Gli Oggetti sono Istanze delle Classi
(Persona)Bill23Maschio
(Persona)Mary32Femmina
•Oggetti ...•Sono definiti dalla loro classe
•Hanno un valore intrinseco per ogni proprietà definita dalla loro classe
•“Conoscono” la loro classe
•Possono essere creati “al runtime”
Classificazione: aspetto chiave dell’Object-Oriented
Classificazione: aspetto chiave dell’Object-Oriented
Person
NomeEtàSesso
•Classe ...•Astrae le proprietà essenziali degli oggetti
•Definisce gruppi di oggetti con proprietà, comportamento, interazioni e semantica simili
•Fornisce un “modello” per costruire un oggetto (è una “fabbrica delle istanze”)
•Definisce le operazioni fornite dalle istanze
42
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8383
Le classi
• Una classe rappresenta una entità di business coinvolta nell’elaborazione (class diagram di business)
• L’individuazione delle classi consente di identificare chi fa che cosa e come all’interno del sistema/azienda
• La struttura delle classi aziendali relative ad un processo può essere confrontata con la definizione di strutture efficienti per la realizzazione (pattern)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8484
Le classi
• Una classe può rappresentare un oggetto concreto (un tornio) oppure immateriale (Iva) o una attività (spedizione)
• Una classe ha delle caratteristiche che la descrivono (attributi), ha delle elaborazioni che vengono eseguite (operazioni), rappresenta una definizione applicabile ad un insieme di elementi omogenei (oggetti)
43
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8585
Le classi
• Le classi sono proiezioni delle entità del dominio del problema entro il dominio del modello• Una classe definisce gruppi di entità con
proprietà, comportamento, interazioni e semantica simili
• Una classe fornisce un “modello” per “costruire” ciascuna di tali entità
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8686
Le classi
• Classe– Prototipo– Modello– Astrazione– Definisce Proprietà e comportamento degli
oggetti
44
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8787
Le Classi devono avere Nomi Concisi e Precisi, presi dal linguaggio del dominio
Sistema OrdiniSistema Ordini
Persona? Venditore Strumento? Prodotto Grafico ? RapportoVendite
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8888
Le classi hanno degli attributi
Colore cofanoTipo fanali…PortieraPneumatico
45
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 8989
Le classi possono avere componenti
DimensioneMarcaTipo (neve, bagnato…)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9090
Oggetti e classi
•Oggetti ...
•Oggetto concreto
•Esempio: l’automobile n.12 della polizia municipale di Parma
•Classe ...•Analoga ad una definizione presente in un dizionario o un’enciclopedia•Esempio: l’auto della polizia
46
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9191
Gli Oggetti sono la “concretizzazione” delle Classi
(Persona)Bill23Maschio
(Persona)Mary32Femmina
PersonaNomeEtàSesso
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9292
I class diagram
• Modellano la relazione fra le entità del sistema, rappresentate come classi
• Le classi possono avere relazioni fraloro, rappresentate con le associazioni
• Per default, un’associazione è bidirezionale, anche se può essere resa unidirezionale
47
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9393
Rappresentazione di una classe: 1) come solo entità
Automobile
Nome della classe
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9494
Rappresentazione di una classe: 1a) come entità + stereotipo
<<strumento>>
Nome della classe
Automobile
Stereotipo della classe
48
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9595
Rappresentazione di una classe:2) entità con attributi
Attributi significativi privati
Automobiletarga : Stringproprietario : Personamarca : Stringpotenza : Integer
Nome della classe
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9696
Rappresentazione di una classe:3) entità + attributi + metodi
Attributi significativi privati
Metodi pubblici:Servizi che l’oggetto “offre” all’esterno
Automobiletarga : Stringproprietario : Personamarca : Stringpotenza : Integer
compra (nuovoProprietario : String)calcolaBollo () : Integer
Nome della classe
49
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9797
Diagramma delle classi
Classe 1 Classe 2
Classe di AssociazioneAttributo
Classe 3
1
*Classe 4
1 *
Classe 5
Sottoclasse 5/1 Sottoclasse 5/2 Sottoclasse 5/3
*
1
Specializzazione
Molteplicità
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9898
Un esempio di associazione
MotorenumeroCilindricilindratapotenza
avvia( )ferma( )
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
Oggetto : classe = link : associazione
Classe
Associazione
Classe
Fra le classi Auto e Motore c’è un’associazione: questo significache fra ogni istanza della classe auto e ogni istanza della classemotore c’è un link
50
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 9999
Cardinalità
• La cardinalità di un’associazione esprime il numero di oggetti di una certa classe che prendono parte all’associazione
• Si esprime con un numero o un rangedisegnati vicino alla classe
MotorenumeroCilindricilindratapotenza
avvia( )ferma( )
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
1 111
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 100100
Cardinalità - 2
• Un auto ha 4 pneumatici, per cui il diagramma diventa
MotorenumeroCilindricilindratapotenza
avvia( )ferma( )
11
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
11
PneumaticoMarcaModelloDiametro411 4
51
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 101101
MotorenumeroCilindricilindratapotenza
avvia( )ferma( )
PneumaticoMarcaModelloDiametro1 1 1 4
PersonaNomeCognome...
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
11 41
0..*
1..*1..*
0..*
Cardinalità - 3
• Inoltre un’auto ha un numero arbitrario di proprietari e una persona può essere proprietaria di una numero arbitrario di auto, quindi...
Zero o più
Uno o più
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 102102
Nomi per le associazioni
• Un’associazione può avere un nome
• Il concetto di “possiede” è però unidirezionale
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
PersonaNomeCognome... 0..*1..* 0..*1..*
Possiede
52
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 103103
Ruoli per le classi
In genere si preferisce usare Ruoli associati a una delle classi
PersonaNomeCognome...
AutomarcamodellotargavelMax
getMarca( )getModello( )getTarga( )avvia( )ferma( )
1..* 0..*0..*1..*
Proprietario
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 104104
Classi di associazione
• Servono ad esprimere attributi e/o metodi propri dell’associazione
• I concetti espressi non appartengono agli oggetti associati ma all’associazione in quanto tale
VeicoloPersona
Nome...0..*
Proprietario
1..*1..*0..*
ProprietàDataInizioDataFine
53
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 105105
Classi di associazione e vincoli
Un veicolo può avereproprietari diversi
(nel tempo)
Per ogni coppiaPersona-Veicolo
esiste una istanzadi ProprietàVincolo
Veicolo2marca : Stringpotenza : Integertarga : String
compra( )
Personacognome : Stringnome : Stringresidenza : Indirizzo 0..*0..*0..* 0..*
proprietario
ProprietadataInizio : DatedataFine : Date
{un veicolo non può avere più proprietari contemporaneamente}
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 106106
Vincoli e note
Nota Nota con riferimento
Nota che esprime un vincolo{condizione del vincolo}
Nome Nome, verso e note associazione
{vincolo} Vincolo “breve”
54
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 107107
Dettagli delle associazioni: le relazioni
Compagnia di assicurazioni
Polizza assicurativa1
Azienda
0..*
Persona
1..* Titolare polizza
Assicuratore
Ha
0..*
0..*
1..*Titolare polizza
E’ assicurataattraverso
E’ assicurataattraverso{xor}
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 108108
Compagnia di assicurazioni
Polizza assicurativa1
Azienda
0..*
Persona
1..* Titolare polizza
Assicuratore
E’ stipulata da
0..*
0..*
1..*Titolare polizza
Assicura Assicura
{xor}
Dettagli delle associazioni: le relazioni
55
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 109109
Class diagram e diagrammi E-R
• I diagrammi di classe rappresentano una evoluzione dei diagrammi E-R
• Vengono inseriti concetti non direttamente rappresentabili negli E-R, quali:– Inclusione– Ereditarietà– Operazioni (metodi) associate alle classi
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 110110
Class diagram e diagrammi E-R: esempio
Squadra<<PK>>idSquadra : Stringnome : String
Calciatore<<PK>>idCalciatore : String
nome : StringCittà : String
<<FK>>idSquadra : String
Squadra Calciatore
(1,1) (1,N)
idSquadra nome cognome nome idCalciatore
1 *
56
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 111111
Attributi che hannoStruttura interna, oppureOperazioni che fanno piùche non semplicemente accedere al suo valore,
dovrebbero essere modellati come Oggetti (connessi)
Attributi che hannoAttributi che hannoStruttura interna, oppureoppureOperazioni che fanno piùche non semplicemente accedere al suo valore,
dovrebbero essere modellati dovrebbero essere modellati come Oggetti (connessi)come Oggetti (connessi)
Cosa accade quando gli Attributi diventano complessi?
Auto
MarcaModelloMotoreColore
AvviamentoStop
Arresta il motoreArresta il motore
Quanti cavalli di potenzaproduce?
Quanti cavalli di potenzaproduce?
Avvia il motoreAvvia il motore
Quanto è grossoil nostro motore?
Quanto è grossoil nostro motore? Motore
Cavalli di cilindrata
AvviamentoStop
Auto
MarcaModelloColore
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 112112
Aggregazione di classi
Auto Polizia
Sportello Sirena Specchio
Auto Polizia
Sportello Sirena Specchio
• Il diamante o rombo che tocca il simbolo di una classe indica che essa contiene gli altri elementi (è un aggregato)
• La linea di relazione conduce dal diamante alle classi componenti
• Forme gerarchiche e multi-diamante hanno lo stesso significato
formealternative
57
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 113113
Diagramma delle classi: l’aggregazione
Spedizione
* Comprende
Una spedizione comprende un certo numero di prodotti(quelli ordinati)Un prodotto può essere compreso in più di una spedizione
*Prodotto
{ordinato}
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 114114
Aggregazione e composizione
Master
*Nome aggregazione
•L’eliminazione di una composizione (diamante nero) elimina anche tutti i suoi elementi componenti•L’eliminazione di una aggregazione (diamante bianco)invece no (i componenti hanno anche una natura Indipendente)
*Detail
{vincolo}
Master
*Nome composizione
*Detail
{vincolo}
58
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 115115
Aggregazione e composizione: esempio
Ordine
1Incluso in
L’eliminazione di un ordine elimina anche le righe ordinema non elimina i prodotti che esse comprendono
*RigaOrdine
*
Prodotto
1
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 116116
Le Generalizzazioni
• Le Generalizzazioni sfruttano le Analogie delle Classi, proprio come le Classi sfruttano le Analogie degli Oggetti
• Le Generalizzazioni sfruttano gli elementi in comune delle Classi
• Le Specializzazioni definiscono le Differenze• Le Gerarchie di Generalizzazione definiscono
una “specie” di relazione
59
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 117117
• Rapporti delle Generalizzazioni– La classe da specificare è una
superclasse– La classe specificata è una sottoclasse– I genitori si riferiscono all’insieme di
tutte le superclassi– I figli si riferiscono all’insieme di tutte le
sottoclassi
La Generalizzazione ha una Simbologia Speciale
sottoclasse sottoclasse
superclasse
sottoclasse
La Simbologia triangolare indica
la Generalizzazione
La Simbologia triangolare indica
la Generalizzazione
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 118118
Cosa è analogo in questi Oggetti?
Modella la gerarchia di questi veicoli
Modella la gerarchia di questi veicoli
60
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 119119
Una possibile gerarchia
Veicolo
Auto
Auto poliziaAmbulanza
dimensione
... ...
Camion
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 120120
Un’altra gerarchia
Veicolo
Auto Polizia
Veicolo d’Emergenza
Ambulanza
uso
Veicolo passeggero
AutoCamion
61
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 121121
Il Discriminante
• Fornisce le Basi per la Specializzazione specificando quale proprietà della “superclasse” è da astrarre
• Valori opzionali, enumerati• Attributo speciale che in altro modo
non appare sul diagramma
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 122122
Il Discriminante
• Solo una proprietà alla volta dovrebbe essere distinta
• Ogni sottoclasse ha un valore unico per il discriminante– Si distingue dalle altre sottoclassi
62
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 123123
Le Sottoclassi ereditano Proprietà dai Genitori
• Le Sottoclassi ereditano gli Attributi, le operazioni e le Associazioni delle loro superclassi– Entrambe le sottoclassi ereditano il Tipo
Sirena e il Suono Sirena• L’esempio di una sottoclasse è un esempio
di tutte le classi genitrici• Specializzazioni delle sottoclassi tramite
l’aggiunta di proprietà uniche– L’ambulanza aggiunge il carico della
vittima, il veicolo della Polizia aggiunge il carico del criminale
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 124124
Le Sottoclassi ereditano Proprietà dai Genitori - 2
Auto Polizia
Veicolo d’emergenza
Ambulanza
Tipo Sirena
Suona Sirena
Carica Malato Carica Criminale
eredita gli attributi delle superclassie le operazioni
eredita gli attributi delle superclassie le operazioni estende gli attributi delle
superclassi e le operazioniestende gli attributi delle superclassi e le operazioni
63
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 125125
L’ereditarietà ci consente di costruire da Componenti Simili
• La nuova classe si costruisce sulle classi esistenti ereditando le proprietà dei genitori nella gerarchia di generalizzazione
• La nuova classe ha bisogno solo d’implementare le estensioni e le differenze
AudioComponente
TapeDeck
AudioComponente
Tape DeckDigitale
TapeDeck
Aggiuntadi una classe
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 126126
La suddivisione in Sottoclassi può essere Esclusiva o Inclusiva
• L’impiegato è retribuito a ore, a stipendio fisso o part time
• Un veicolo è un veicolo di terra, un veicolo d’acqua o entrambi.
Retribuitoa ore
A stipendiofisso
ImpiegatoPart-time
Impiegato
{Esclusiva}
Veicolo
Veicolodi terra
Veicolod’acqua
{Inclusiva}
64
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 127127
Il passaggio da entità a classi
ENTITA’ CATEGORIA CLASSE
Astrazione Formalizzazione
RaccoltaCaratteristicheComuni
MondoReale(dominio di Business)
Definizioni,idee
ProgettoFormale
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 128128
Diagramma delle classi: dipendenza
Sistema informativo
L’Azienda dipende dal sistema informativo, che viene Realizzato attraverso un sistema informativo basato sull’information technology
Azienda
Sistema Informativobasato su IT
65
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 129129
Classi e risorse
<<Abstract>>Azione
<<Physical>>Trapano
<<People>>Venditore
<<Information>>Business news
Gli stereotipi definiscono concetti che personalizzanole entità modellizzate con le classi
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 130130
Classi e risorse: metamodelli
• Attraverso i class diagram è possibile esprimere anche concetti costitutivi di altre classi e/o categorie
• Si possono costruire quindi dei metamodelli
66
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 131131
Metamodelli: esempio
Resource
InformationThing
Abstract Physical
People
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 132132
Class diagram ed object diagram
• Gli object diagram sono simili ai class diagram, ma i loro componenti sono gli oggetti, ossia istanze ben definite delle classi
• In pratica quindi un object diagram rappresenta un insieme di legami logici caratteristici di di entità concrete e non astratte
67
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 133133
Object diagram: sintassi
Fiat Punto JTD BJ998RS :
Nome della classe
Automobile
Nome dell’oggetto
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 134134
Classi ed oggetti: organizzazione
Azienda
Il modello organizzativo dell’azienda può essere rappresentato efficacemente con un class diagram
Management
Divisione
Sezione
*
*
1
68
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 135135
Organizzazione effettiva: object diagram
Alfa S.r.l.:Azienda
Soci:Management
Amministrazione:Divisione
Contabilità:Sezione
1
Vendite:Divisione
Acquisti:Divisione
Produzione:Divisione
Personale:Sezione
Accessori:Sezione
Tendaggi:Sezione
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 136136
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
69
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 137137
Diagrammi di sequenza
• Descrivono le interazioni fra gli oggetti organizzate in sequenza temporale
• Uno use case contiene al suo interno vari diagrammi di sequenza
• Salvo casi banali, non si rappresentano all’inizio tutte le possibili sequenze, ma solo le principali
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 138138
Diagrammi di sequenza: gli elementi
• Elementi costitutivi di un diagramma di sequenza:– gli oggetti– i messaggi attraverso cui essi interagiscono.
• Lo scambio di messaggi è rappresentato da frecce con un nome.
70
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 139139
Diagrammi di sequenza: i messaggi
In base al livello di dettaglio• I messaggi possono esplicitamente far
riferimento ai metodi (operazioni) effettivamente coinvolti, ossia richiamati;
• Possono essere specificati anche i parametri e/o i risultati;
• Oppure viene descritta un’azione generica.
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 140140
Diagrammi di sequenza: il controllo
• Ripetizioni cicliche (for, while)
• Condizioni (if, case)
71
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 141141
Diagrammi di sequenza: messaggi e azioni
• Call: invoca un metodo di un oggetto; un oggetto può inviare un messaggio a se stesso, invocando un proprio metodo
• Return: restituisce un valore al chiamante
• Send: invia un signal ad un oggetto• Create: crea un oggetto• Destroy: distrugge un oggetto; un
oggetto può distruggere se stesso
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 142142
Diagrammi di sequenza: sequenze di messaggi
• Uno scambio di messaggi può dare origine ad una sequenza
• La sequenza deve avere un punto d’inizio (“evento scatenante”)
• Può essere utile anteporre numeri ai nomi dei messaggi
72
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 143143
Sequence Diagram: simboli base
Nome del diagramma di sequenza (di solito in fondo)
Oggetto di riferimento con nome “oggetto1”
Asse dei tempi diretto verso il basso
Messaggio in partenza (comando inviato)
Oggetto1
Richiesta fatta
Richiesta ricevuta/risposta Messaggio (comando) ricevuto
Durata temporale (opzionale) di un’azione, ovvero periodo durante il quale l’oggetto controlla il flusso
(Focus of control)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 144144
Sequence Diagram: tipi di entità
Oggetto di riferimento con nome “oggetto1”Oggetto1:
Oggetto di riferimento con nome “oggetto1”, istanza della classe “classe1”
Oggetto1: Classe1
Oggetto di riferimento, istanza generica della classe “classe1”
(tutti gli oggetti di quella classe)[:]Classe1
73
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 145145
Sequence Diagram: tipi di messaggi
Semplice: il controllo è passato dal chiamanteal ricevente
Sincrono: il controllo è passato dal chiamanteal ricevente ed il primo attende che il secondo
gli restituisca il controllo
Asincrono: il chiamante trasmette un segnaleal ricevente ma prosegue poi nelle proprie
azioni senza attendere il secondo che può o menoritornare informazioni
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 146146
Esempio di diagramma di sequenza: offerta
:Cliente :Fornitore
InvioRichiesta di offerta
Preparazioneofferta
Accettazione/Preparazione
ordine
Preparaz.Richiesta di offerta
Invioofferta
Preparazionespedizione
Invioordine
Inviomerci
74
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 147147
Esempio di diagramma di sequenza: bancomat
:Cliente :Bancomat
Verificadisponibilità
contante
:Dispenser
PreparazioneBanconote e
scontrino
VerificaCodice
Inserimento codice
Abilitazione/rifiuto
Indicazione contante
SI: Dispensa il contanteNO: fondi insufficienti
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 148148
Esempio di diagramma di sequenza: telefono
C:Utente:Sistema
Telefonico
Connetti(R)
R:Utente
CreaCircuito
Attiva Linea
SegnalaLineaLibera()
ComponiNumero(num)
Crea()
M:Chiamata
Suona()
Rispondi
Connetti(C)
75
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 149149
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 150150
Diagrammi di collaborazione
• Sono semanticamente equivalenti ai diagrammi di sequenza: entrambi sono visualizzazioni di scenari
• I diagrammi di collaborazione enfatizzano le relazioni fra oggetti (ovvero l’organizzazione strutturale), i diagrammi di sequenza enfatizzano la sequenza temporale delle comunicazioni
76
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 151151
Diagrammi di collaborazione - 2
• La sequenza dei messaggi è meno evidente che nel diagramma di sequenza, mentre sono più evidenti i legami tra gli oggetti
• I messaggi hanno sempre espresso l'ordine di sequenza
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 152152
Diagrammi di collaborazione - 3
• I diagrammi di collaborazione vengono usati prevalentemente in fase di progetto, quelli di sequenza in fase di analisi, perché sono più comprensibili da parte del committente (cliente, esperto del dominio)
• I due diagrammi sono isomorfi, èpossibile cioè trasformare uno nell’altro
77
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 153153
Collaboration Diagram: simboli base
Nome del diagramma di collaborazione (di solito in fondo)
Oggetto di riferimento con nome “oggetto1”
Messaggio in partenza (comando inviato),con numero di sequenza
Oggetto1
1: Richiesta fatta
2: Richiesta ricevuta/risposta Messaggio (comando) ricevuto,
con numero di sequenza
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 154154
Collaboration Diagram: tipi di entità
Oggetto di riferimento con nome “oggetto1”Oggetto1:
Oggetto di riferimento con nome “oggetto1”, istanza della classe “classe1”
Oggetto1: Classe1
Oggetto di riferimento, istanza generica della classe “classe1”
(tutti gli oggetti di quella classe)[:]Classe1
78
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 155155
Esempio di diagramma di collaborazione: bancomat
:Cliente
:Bancomat
:Dispenser
1: Inserimento codice
2: Abilitazione/rifiuto3: Indicazione contante
4: SI: Dispensa il contante
4: NO: fondi insufficienti
5: Contante
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 156156
Esempio completo: sequenza
get_prezzo (prodotto_id)
: cassiere: POST : Vendita : Riga vendita : Prodotto
porzione del caso d'uso"Acquistare articoli"relativa alla
registrazione articoli
registra_articolo (prodotto_id, qta)[nuova vendita] crea vendita ( )
crea riga vendita (prodotto_id, qta)
[vendita in corso] aggiungi riga vendita ( )
oggetto
messaggio
79
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 157157
Esempio completo: collaborazione
: cassiere
: POST : Vendita
: Riga vendita
: Prodotto
1: registra_articolo (prodotto_id, qta)
2: [nuova vendita] crea vendita ( )3: [vendita in corso] aggiungi riga vendita ( )
4: crea riga vendita (prodotto_id, qta)5: get_prezzo (prodotto_id)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 158158
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
80
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 159159
Activity Diagram (diagrammi d’attività)
• Rappresentano una procedura o un workflow
• Mostrando l’evoluzione di un flusso di attività
• Ogni attività è definita come un’evoluzione continua, non necessariamente atomica, di uno stato
• Sono una evoluzione dei flow-chart
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 160160
Activity Diagram: elementi base
• Activity (Attività)Esecuzione non atomica entro un sistema dotato di stati.Può essere scomposta in azioni.
• Action (Azione)Operazione atomica eseguibile che produce come risultato un cambiamento nello stato di un sistema o il ritorno di un valore.
81
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 161161
Activity Diagram: concetti base
• Action State (Stato di azione)Uno stato che rappresenta l'esecuzione di un'azione (atomica), tipicamente l'invocazione di una operazione.
• Activity State (Stato di attività)Stato composito, in cui il flusso di controllo è formato di altri stati di attività e stati di azione. Non è atomico, il che significa anche che può essere interrotto. Può anche essere ulteriormente scomposto in altri diagrammi di attività
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 162162
Activity Diagram: elementi di contorno
• Transition (Transizione)Rappresenta il flusso di controllo fra due attività, che mostra il percorso da un action o activity state al successivo action o activity state.
• Object Flow Rappresenta un oggetto (un'entità) coinvolta nel flusso di controllo associato con un activity diagram.
82
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 163163
Activity Diagram: elementi di contorno
• Object State Una condizione o situazione operativa nella vita di un oggetto (un'entità) durante la quale l'oggetto soddisfa certe condizioni, compie certe attività o attende certi eventi.
• Swimlane Una suddivisione per l'organizzazione di responsabilità per le attività. Non ha un significato fisso, ma spesso corrisponde alla unità organizzativa entro un business model (es. ufficio acquisti, vendite...).
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 164164
Activity Diagram: tipologie
• Activity state (Diagram)Le singole attività hanno una durata e possono essere ulteriormente scomposte, dando origine ad altri diagrammi
• Action state (Diagram)Le singole attività sono atomiche e non possono essere ulteriormente scomposte
83
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 165165
Activity Diagram: significato
• Enfasi posta sulle attività e non su chi le compie
• Enfasi sulla sequenza di azioni di una particolare procedura
• Vengono evidenziati vincoli di precedenza o di concorrenza
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 166166
Activity Diagram: simboli base
Non vi è differenza fra simboli di attività e simboli di azioneNome del diagramma di attività (in fondo)
Attività 1
Inizio di un diagramma di attività
Termine di un diagramma di attività
Singola attività generica con nome “Attività 1”
Connessione fra attività
Attività 2 Subattività generica (scomponibile)
84
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 167167
Activity Diagram: simboli di invio/ricezione
Invio 2 Attività con invio e ricezione con nome “Invio 2”
Attività con invio con nome “Invio 1”
Attività con ricezione con nome “Ricezione 1”Ricezione 1
Invio 1
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 168168
Tipi di AD: sequenza semplice
Attività 1
Un’attività (Attività 2) viene eseguita dopo la fine della Precedente (Attività 1)
(Single Thread)
Attività 2
85
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 169169
Tipi di AD: AND-split
Attività 1
Un singolo flusso di attività si divide in più flussi, consentendo l’esecuzione simultanea di più attività
(Multiple Thread)
Attività 3
Attività 2
Attività 4
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 170170
Tipi di AD: AND-join
Attività 5
Due o più flussi di attività convergono in uno soloE’ un punto di sincronizzazione per il workflow: non si va
avanti finché non sono terminate tutte le attività precedenti
Attività 3
Attività 2
Attività 4
86
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 171171
Tipi di AD: OR-split
Attività 1
Un singolo flusso di attività prosegue per uno dei cammini in base al verificarsi delle condizioni di transizione,
indicate fra parentesi quadre
Attività 3
Attività 2
Attività 4
[C2]
[C3]
[C4]
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 172172
Tipi di AD: OR-join
Attività 5
Un punto dove due o più flussi di attività ri-convergono in uno soloovvero hanno tutti Attività 5 come elemento successivo
Attività 3
Attività 2
Attività 4
87
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 173173
Tipi di AD: iterazione
Attività 1
Un’attività (Attività 2) viene ripetuta più volte,in base al verificarsi o meno di opportune condizioni
di controllo
Attività 2 Attività 3
[C2]
[C1]
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 174174
Activity Diagram: esempi vari
Se il costo totale è maggiore di 200€, bisognachiedere l’autorizzazione prima di addebitarlo al
cliente.
Addebitareal cliente
Calcolare il costo totale
Richiedereautorizzazione
[Costo <= €200]
[Costo > €200]
88
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 175175
Activity Diagram: flusso di oggetti
Verifica delprodottoProduzione
<<Physical>>Prodotto
[verificato]
<<Information>>Feedback
sul prodotto
<<Physical>>Prodotto
[costruito]
<<Abstract>>Ordine
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 176176
Activity Diagram con processi
Nome del diagramma di attività
Attività 1 Attività 2Processo 1
Processo 2
89
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 177177
Activity Diagram con processi: esempio
Calibrazione del trapano
Attivare il trapano
<<Processo>>Fare un buco
<<Processo>>Trapanazione
Perforare Fermare il trapano
<<Processo>>Fare un buco
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 178178
Diagrammi UML
• Use Case Diagram• Class Diagram• Sequence Diagram• Collaboration Diagram• Activity Diagram• Statechart Diagram
90
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 179179
Statechart Diagram: diagrammi di stato
• Possono essere usati per descrivere il comportamento nel tempo di un particolare elemento come
• un oggetto (ovvero una singola entità) • un intero sottosistema
• ovvero l'evoluzione di una interazione.
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 180180
Statechart Diagram: diagrammi di stato
In pratica essi descrivono• sequenze di stati ed azioni attraverso
cui l'elemento considerato passa durante la propria vita
• reagendo a eventi discreti (segnali, chiamate a funzionalità...).
91
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 181181
Statechart Diagram: diagrammi di stato
• Si possono pensare come “il contrario” degli Activity Diagram
• Enfasi posta sugli stati e non sulle azioni
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 182182
Statechart Diagram: simboli base
Nome del diagramma di stato (in fondo)
Stato 1
Inizio di un diagramma di stato
Termine di un diagramma di stato
Singolo stato generico con nome “Stato 1”
Connessione fra stati
Stato 2 Stato scomponibile in un ulteriorediagramma di stati
92
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 183183
Statechart Diagram: simboli base
Stato con attività in corso per tutta la sua durataStato 1
Do: attività
Stato con attività che accade all’ingresso in essoStato 1
Enter: attività
Stato con attività che accade all’uscita da essoStato 1
Exit: attività
Stato che include un’attività compiuta suun altro diagramma
Stato 1
Include: attività
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 184184
Tipi di SD: punto di scelta dinamica
Stato 1
In base alle condizioni si passa ad uno degli stati.Forma equivalente: le frecce partono direttamente da
Stato 1
Stato 3
Stato 2
Stato 4
[C2]
[C3]
[C4]
93
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 185185
Tipi di SD: punto di giunzione
Stato 5
Il successivo di tutti e 3 gli stati, seguendo le condizioni,è Stato 5
Stato 3
Stato 2
Stato 4
[C2]
[C3]
[C4]
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 186186
Statechart Diagram: esempio
I rettangoli rappresentano uno stato per le entità in gioco
Non pagata Pagata
Fatturacreata
Pagamento / Fatturaarchiviata
94
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 187187
Statechart Diagram: terminazione a due possibilità
Ordine creato
Ordinericevutodal cliente
Immissionenel mercato
/ Ordinearchiviato
Ordine immesso
nel mercato
Ordine completato
Ordinecancellato
Ordinefallito
Corrispondenzetrovate/concluso
Fine scambi
Re-immiss.nel mercatoIl giorno dopo
Accettare fallimento/ fallito
CancellareOrdine /cancellato
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 188188
Statechart Diagram: inserimento di oggetti
mode()Display
Do/ mostraOra corrente
Imposta ore
Do/ mostraOre
Imposta minuti
Do/ mostraminuti
Orologio Digitale
mode()Incrementa()
mode()
mode()
Inc /ore := ore + 1 mod 24 Inc /min := min + 1 mod 60
95
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 189189
I Package di UML
Un package è un raggruppamento generale di elementi correlati fra loro da un legame logico che il modellatoreritiene importante. I package possono essere inseriti intutti i diagrammi UML
Nome/descr.
Classe1 Classe2
Classe3 Classe4
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 190190
Diagrammi UML
I diagrammi di analisi• Class Diagram• Activity Diagram• Statechart Diagram• Use Case Diagram• Sequence Diagram• Collaboration DiagramCome sono imparentati fra loro?
96
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 191191
Il legame fra i diagrammi UML
USE CASEDIAGRAM
ACTIVITYDIAGRAM
CLASS DIAGRAM
COLLABORATIONDIAGRAM
SEQUENCEDIAGRAMSTATECHART
DIAGRAM
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 192192
Il legame fra i diagrammi UML
FUNZIONALITA’
PROCESSI
ENTITA’
INTERAZIONITRA LE ENTITA’
FLUSSOOPERATIVOSTATO DEI
PROCESSI
97
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 193193
Implementazione
Diagrammi di implementazione:• Component Diagram• Deployment Diagram
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 194194
Component Diagram: i componenti
• Un componente rappresenta un pezzo “fisico” dell’implementazione di un sistema
• La granularità della suddivisione del sistema dipende fortemente – dal contesto e – dal livello di astrazione in cui ci si pone
98
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 195195
Component Diagram: i componenti - 2
Attraverso l'uso degli stereotipi vengono classificati diversi componenti(lo standard UML ne definisce 5)– programma eseguibile (es .exe):
<<executable>>– libreria statica (es. .h) o dinamica (es.
.dll): <<library>>– file di codice sorgente o dati (es. .cpp):
<<file>>– documento (es. .htm): <<document>>– tabella di database: <<table>>
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 196196
Component Diagram: i componenti - 3
Un componente ha un nome e una locazione
• è mostrato, tipicamente, con il solo nome
• per le classi, è possibile inserire compartimenti riportanti altri dettagli (analogia col class diagram)
• è possibile indicare le relazioni tra componenti e classi e/o interfacce che essi realizzano
99
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 197197
Component Diagram: i componenti - 4
• I componenti (come a livello logico le classi o altri elementi dei diagrammi) possono essere raggruppati in package
• Se i componenti sono file, i package sono cartelle/ directory
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 198198
Component Diagram: il diagramma dei componenti
• Rappresenta l’implementazione del sistema, attraverso la visione dei suoi elementi costitutivi
• Un componente rappresenta un pezzo “fisico” dell’implementazione di un sistema
• La suddivisione dipende dalla granularità del modello
100
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 199199
Component Diagram: il diagramma dei componenti - 2
• Definisce le relazioni fra i componenti software che realizzano l’applicazione– sorgenti, binari, eseguibili, …
• Può operare a livelli diversi, ad esempio:– nella fase di sviluppo di un’applicazione
può esprimere la struttura di un makefile– nella fase di installazione può indicare le
dipendenze da librerie, file di configurazione…
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 200200
Component Diagram: il diagramma dei componenti - 3
• Può rappresentare parte della specifica architetturale
• Evidenzia l'organizzazione e le dipendenze esistenti tra componenti
• Evidenzia anche la distinzione fra i diversi componenti e le varie interfacce che essi offrono e usano
• Primo passo verso Component Programming
101
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 201201
Component Diagram: il diagramma dei componenti - 4
• Le interfacce rappresentano insiemi di operazioni (metodi) che definiscono un servizio
• Un componente può usare le interfacce di altri componenti
• Un componente può provvedere le proprie interfacce
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 202202
Component Diagram: simboli base
Nome del diagramma dei componenti (in fondo)
Singolo componente generico con nome “Componente 1”
Relazione fra componenti con <<tipo>>,di solito dipendenza
Componente con due interfacce, aventi nome interfaccia 1 e 2
Componente 1
Componente 2
<<tipo relazione>>
Interfaccia 1
Interfaccia 2
102
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 203203
Esempio: eseguibile e librerie
<<library>>
Swing.jar
<<library>>
JDBC.jar
<<executable>>
ProgrammaGestione ordini
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 204204
Component Diagram: simboli alternativi
• Non esistono standard “assoluti” sui simboli da usare per i componenti
• Per esempio – Un file di testo può essere indicato con
l’icona del blocco note– Un documento con l’icona del documento– Una libreria con un quadrato con
ingranaggi
103
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 205205
Component Diagram e altri diagrammi
• Le corrispondenze fra gli elementi del Component Diagram e gli elementi di altri diagrammi dipendono dalle scelte fatte nella granularità del problema
• Ad esempio un singolo componente può corrispondere ad una classe, ad un intero gruppo di classi o un’intera applicazione
• I package possono essere di aiuto per chiarificare le cose
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 206206
Esempio: il package come “contenitore”
Tabellaordini
Tabellaprodotti
FormGestione ordini
Database
104
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 207207
Categorie di componenti: deployment
I deployment components sono i componenti necessari e sufficienti per formare un sistema eseguibile
• Eseguibili (exe, com…)• Librerie (DLL, .so, .jar...)• File di configurazione propri del
programma
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 208208
Categorie di componenti: work product
• I work product components sono componenti che non partecipano direttamente nel sistema eseguibile ma che sono frutto del lavoro fatto per creare il sistema eseguibile
• Essenzialmente si possono pensare come il “residuo” del processo di sviluppo– File sorgenti– File di configurazione dei progetti (project
file o XML file di ants o nants…)– Data file usati per la creazione di
deployment
105
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 209209
Categorie di componenti: execution
• Gli execution component sono componenti creati per permettere il funzionamento del sistema eseguibile
• Dipendono fortemente dall’ambiente (sistema operativo e “infrastrutture”) entro cui il sistema eseguibile opera– COM+ object– JCL – Interfaccia verso MQseries
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 210210
Deployment Diagram
• Rappresenta la distribuzione dei componenti di un sistema eseguibile fra le risorse disponibili
• La granularità della suddivisione del sistema dipende fortemente – dal contesto e – dal livello di astrazione in cui ci si pone
106
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 211211
Deployment Diagram - 2
• Il diagramma può essere riferito a risorse hardware (es. server, nodi di calcolo)
• Oppure a macroelementi software (es. mappatura dei componenti logici entro i processi)
• O anche a sistemi informatici completi (es. sistemi informatici distribuiti), in congiunzione con collaboration diagram
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 212212
Deployment Diagram - 3
In pratica quindi• Consente di rappresentare, a diversi
livelli di dettaglio, l’architettura fisica (hardware e software) di un sistema
• Ma anche di evidenziare la configurazione (run-time o no)– dei singoli nodi elaborativi– dei singoli componenti software (processi,
oggetti…)
107
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 213213
Deployment Diagram: simboli base
Nome del diagramma di dislocazione (in fondo)
Singolo nodo (semplice)generico con nome “Nodo 1”
Comunicazione fra nodi con <<tipo>>,di solito indicante il protocollo
<<tipo comunicazione>>
Nodo 1
Relazione/nota esplicativanota
Singolo nodo (esteso)generico con nome “Nodo 2”e indicazione dei componenti
Nodo 2
GUI
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 214214
Deployment Diagram: simboli alternativi
• Anche per il deployment sono usati spesso altri simboli
• Per esempio – Un DB server può essere indicato col
cilindro– Un server con un computer stilizzato– Una postazione client con il monitor
stilizzato
108
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 215215
Deployment Diagram: esempio
Esempio di semplice sistema client/server
Client
Server DBServer
Firewall
<<TCP/IP>>su rete pubblica
<<Fast Ethernet>>
<<Fast Ethernet>>
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 216216
Deployment e Component Diagram
• Alle volte per completezza si possono inserire componenti anche nei deployment diagram
• In generale– componenti sono “entità” che partecipano
nell’esecuzione di un sistema– nodi sono “entità” che eseguono
componenti– componenti rappresentano il packaging
fisico di altri elementi logici– nodi rappresentano l’allocazione fisica di
componenti
109
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 217217
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 218218
Un processo del mondo reale: la spesa
Utente
Processo “spesa”
Necessitàdi comprare
prodotti
Prodottiacquistati
Sistema supermercato
110
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 219219
Quali sono i limiti di un sistema?
Utente
Sistema: utente 2 + negozioProcesso: “fai la spesa”
Lista dei prodotti
da comprare
Prodottiacquistati
Utente 2
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 220220
Le funzionalità della spesa: use case
Utente
Preparazione della lista
Acquisto dei prodotti
Pagamento dei prodotti
111
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 221221
Le funzionalità della spesa: use case
Utente
Preparazione della lista
Acquisto dei prodotti
Pagamento dei prodotti
Raggiungere il supermercato
Ritorno A casa
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 222222
Spesa: Diagramma di attività 1
Preparazionedella lista
Acquisto dei prodotti
Pagamentodei prodotti
112
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 223223
Spesa: Diagramma di attività 1
Preparazionedella lista
Acquisto dei prodotti
Pagamentodei prodotti
ComputoDenaro
spendibile
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 224224
Spesa: Diagramma di attività 2
Preparazionedella lista
Acquisto dei prodotti
Pagamentodei prodotti
Ricevimentodei prodotti
Utente 1: capo Utente 2: esecutore
113
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 225225
Spesa: cercare le classi
Lista
Carrello Prodotti
Pagamento
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 226226
Spesa: Diagramma delle classi
Lista Prodotti
ListaSpesaDataEvasione
Cassa
1
*Carrello
1 *
Pagamento
CartaCredito Bancomat Contanti
*
1
114
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 227227
Spesa: Class Diagram completo
Amministratore
Cassiere
Negozionomeindirizzo
Prodotto
POST
*
1
*
1
avviato da11 11
utilizzato da
1..* 11..* 1
Riga vendita0..*
1
0..*
1
Venditadataora
crea_vendita()
11*
1..* 11..* 1
ha
Pagamentoimporto
11
1riferito a
Pag. Contanti
Pag. Carta Credito
associazione
specializzazione /generalizzazione
Pag. Bancomat
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 228228
Spesa: Class Diagram completo
Amministratore
Cassiere
Negozionomeindirizzo
Prodotto
POST
*
1
*
1
avviato da11 11
utilizzato da
1..* 11..* 1
Riga vendita0..*
1
0..*
1
Venditadataora
crea_vendita()
11*
1..* 11..* 1
ha
Pagamentoimporto
11
1riferito a
Pag. Contanti
Pag. Carta Credito
associazione
specializzazione /generalizzazione
Pag. Bancomat
115
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 229229
Spesa: diagramma di sequenza
get_prezzo (prodotto_id)
: cassiere: POST : Vendita : Riga vendita : Prodotto
porzione del caso d'uso"Acquistare articoli"relativa alla
registrazione articoli
registra_articolo (prodotto_id, qta)[nuova vendita] crea vendita ( )
crea riga vendita (prodotto_id, qta)
[vendita in corso] aggiungi riga vendita ( )
oggetto
messaggio
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 230230
Spesa: collaborazione
: cassiere
: POST : Vendita
: Riga vendita :
Prodotto
1: registra_articolo (prodotto_id, qta)
2: [nuova vendita] crea vendita ( )3: [vendita in corso] aggiungi riga vendita ( )
4: crea riga vendita (prodotto_id, qta)5: get_prezzo (prodotto_id)
116
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 231231
Activity Diagram: il processo generico
Processo 1
<<process>>
<<physical>>
Input1
<<physical>>
OggettoServizio1
<<people>>
Persona1
<<goal>>
Obiettivo1
<<physical>>
Output1
<<information>>
Informazione1
<<information>>
InformazioneA
<<supply>> <<supply>>
<<control>> <<achieve>>
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 232232
Esempio di AD: vendita di siti Web
Vendita Siti Web
<<process>>
<<people>>
Venditore
<<physical>>
Materiali per lavendita
<<people>>
SalesManager
<<goal>>
ObiettivoVendite
<<abstract>>
Ordine
<<information>>
Informazioni per La vendita
<<information>>
Previsione
<<supply>> <<supply>>
<<control>> <<achieve>>
<<information>>
Prospetto
<<information>>Direttive vendita
<<supply>>
<<control>>
117
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 233233
Un esempio di goal: l’obiettivo vendite espanso
fatturato: valuta = € 125.000,00costi: valuta = € 75.000,00scadenza: data = 31/12/2003
<<goal>>ObiettivoVendite:
quantitativo
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 234234
Combinazione AD/swimlanes
Vendita Siti Web<<process>>
<<people>>Cliente
<<abstract>>
Ordine
<<physical>>
Sito Web
<<information>>Profilo del
cliente
<<supply>><<supply>><<supply>>
<<control>>
Web Design<<process>>
<<people>>HTML people
<<people>>WebMaster
118
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 235235
Class Diagram per regole business
1
<<people>>Cliente
<<abstract>>Contratto
<<physical>>Proprietà
<<business rule>>Affitto = 0,15 * Proprietà.valore
{Cliente.reddito > € 30.000}
0..n
affittuario
firma
si riferisce a
affittato
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 236236
I Package in UML for Business
Un package rappresenta un raggruppamento di elementi correlati fra loro, per esempio i profili professionali cheformano una Web agency
Area Internet/profili professionali dell’area
<<resource>>HTML people
<<resource>>Venditori
<<resource>>WebMaster
<<resource>>Web Designer
119
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 237237
Assembly line
Processo X<<process>>
Processo Y<<process>>
Ufficio A
Ufficio B
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 238238
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
120
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 239239
Use Case: vendita pezzi meccanici via Web
Cliente
VenditaComponenti meccanici
Sistema: azienda produttrice su web
Acquista
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 240240
Le entità coinvolte nel processo
• Cliente• Sito Web• Amministrazione • Produzione/Magazzino• Logistica• Banca
121
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 241241
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 242242
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
122
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 243243
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 244244
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
123
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 245245
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
6. Preparazionedella spedizione
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 246246
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
1. Il clientecompleta l’ordine
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
6. Preparazionedella spedizione
7. Spedizioneal cliente
124
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 247247
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
8. Verificae ritornoconfermaaccettazionemerce
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
6. Preparazionedella spedizione
7. Spedizioneal cliente
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 248248
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
8. Verificae ritornoconfermaaccettazionemerce
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
6. Preparazionedella spedizione
7. Spedizioneal cliente
9. Emissionefattura
125
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 249249
Ciclo attivo: collaboration diagram
BancaBanca
Sito WebSito Web
LogisticaLogistica
AmministrazioneAmministrazione
GatewayBanca
GatewayBanca
ClienteCliente
8. Verificae ritornoconfermaaccettazionemerce
Produzione/Magazzino
Produzione/Magazzino
2. Verificadisponibilitàprodotti3. Convalida
e trasmissioneordine
4. Verificaposizionecliente
5. Preparazionedel lotto corrispondenteall’ordine
6. Preparazionedella spedizione
7. Spedizioneal cliente
9. Emissionefattura
10. Pagamentofattura
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 250250
Il ciclo attivo visto per processi
Ordinevia Web
<<process>>Gestione Amm.
Ordine
<<process>>
PreparazioneLotto
<<process>>Spedizione
<<process>>
Verifica Banca<<process>>
RicezioneE verifica
<<process>>
Avvio praticaproduzione
<<process>>
Emissionefattura
<<process>>
Cliente
Cliente
Amministrazione
Amministrazione
Amministrazione/Banca
Magazzino Logistica
Amministrazione
126
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 251251
Il ciclo attivo visto per processi
<<people>>Cliente
<<abstract>>
Ordine
<<physical>>
Sito Web
<<information>>Profilo del
cliente
<<supply>><<supply>><<supply>>
<<control>>
Ordine via Web<<process>>
<<people>>Web Admin
<<information>>Catalogo
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 252252
Altri processi nel ciclo attivo
<<people>>Cliente
<<abstract>>
Ordine
<<physical>>
Sito Web<<information>>Profilo del
cliente
<<?>> <<?>>
<<?>>
?<<process>>
<<people>>Web Admin
<<information>>?
<<people>>Magazzino
<<people>>Spedizioni
<<people>>Amministrazione
127
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 253253
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 254254
Un Pattern…
• descrive un problema • che ricorre in specifici contesti• propone un generico, ma ben
dimostrato, schema per la sua soluzione.
128
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 255255
Quindi un Pattern è
• una soluzione • ad un determinato problema • in un definito contesto
• che, talvolta, può essere generalizzata ed adattata a molti contesti diversi
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 256256
E un Business Pattern
• Si riferisce a problemi di Business• Tipicamente analizza situazioni di
modellizzare e/o strutturare risorse business che comprendono documenti, organizzazione, informazioni
129
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 257257
Suddivisione dei Business Pattern
• Risorse e ruoli (Resource and Role patterns)
• Obiettivo (Goal patterns)
• Processo (Process patterns)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 258258
La coda: pattern di processo
Utente
Coda
Servizio1..n
Coda
Numero postiTempo medio attesa
130
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 259259
L’impiego: pattern di ruolo
PersonaNomeIndirizzoData di nascita
Contratto
Istruzioni operative
Impiego
Data di assunzioneData di licenziamento
OrganizzazioneNomeIndirizzoScopo
1..*
ha
1..*
con
ha*
Espresso con
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 260260
L’impiego: pattern di ruolo
PersonaNomeIndirizzoData di nascita
Impiego
Data di assunzioneData di licenziamento
OrganizzazioneNomeIndirizzoScopo
1..*
Dipendente
1..*
Datore di lavoro
coordinaDirettore
Impiegato
1
1..*
131
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 261261
L’impiego: pattern di ruolo
PersonaNomeIndirizzoData di nascita
Posizione/ruoloAssegnamenti
Impiego
Data di assunzioneData di licenziamento
OrganizzazioneNomeIndirizzoScopo
1..*ha
1..*definisce
Con lo scopo 1..*
con
Occupato attraverso
1..*
1..*
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 262262
Business goal allocation: goal pattern
Processo A
<<process>><<resource>>
Materia prima
<<goal>>Obiettivo
del processo
<<abstract>>
Prodotto
<<achieve>><<achieve>>
<<goal>>Obiettivo
del prodotto
132
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 263263
I goal nella vendita di siti Web
Vendita Siti Web
<<process>>
<<people>>
Venditore
<<physical>>
Materiali per lavendita
<<people>>
SalesManager
<<goal>>
ObiettivoVendite
<<abstract>>
Ordine
<<information>>Informazioni per
La vendita
<<information>>
Previsione
<<supply>> <<supply>>
<<control>> <<achieve>>
<<information>>
Prospetto
<<information>>Direttive vendita
<<supply>>
<<control>>
<<goal>>Customer
Satisfaction
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 264264
Argomenti
• Il contesto: la realtà e la sua modellazione• I sistemi informativi• L’evoluzione di UML• Dall’IT modeling al business modeling• Come si usano i diagrammi• Esempi di processi e attività business• Case study• I pattern nell’analisi del business• La visione dell’IT con oggetti e Web Services
133
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 265265
Uso di UML: il mercato IT
• Avvento dei linguaggi Object-Oriented• Mosse degli attori principali dell’IT
– IBM acquista Rational (Ottobre 2002)– Microsoft acquista Navision e Great Plain
(Novembre 2002)– Avvento dei Web Services per l’integrazione
(2001-2002)– IBM, Microsoft e Bea annunciano
congiuntamente lo standard comune BPEL4WS (estate 2002)
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 266266
Uso di UML: il mercato IT
• I sistemi informativi OO-based (spot televisivi di Microsoft e IBM)
• “Interconnessione totale” entro l’azienda
• Flessibilità ed economicità delle strutture IT
• Riorganizzazione rapida ed efficace dei processi informativi (e quindi anche di quelli produttivi)
134
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 267267
Uso di UML: il mercato IT
• Individuazione degli “oggetti esecutivi”che compiono le varie fasi di cui ogni processo si compone
• Riduzione a “fattor comune” degli oggetti medesimi
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 268268
Uso di UML: il mercato IT
• Oggetti che possono corrispondere alla “storica” suddivisione dell’azienda in unità funzionali (vendite, marketing, amministrazione…)
• O anche a unità funzionali “più piccole”entro l’azienda, in funzione della scomposizione fatta e della conseguente “granularità” della ingegnerizzazione del processo
135
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 269269
Uso di UML: il mercato IT
• La tecnologia dei Web Services puòcondurre alla realizzazione della infrastruttura IT per una organizzazione di questo tipo entro l’azienda:“Sovrapponendosi” all’esistenteSenza stravolgere l’esistente
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 270270
Web Services (Servizi Web)
• Server Web
• Offrono possibilità di interazione completa (RPC) tramite SOAP
• Offrono ogni tipo di servizio
136
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 271271
Oggetto
Metodo 1Metodo 1Il messaggio è l’invocazione diun metodo Metodo 2Metodo 2
Metodo 3Metodo 3
Metodo 4Metodo 4
Messaggio
Oggetto“server”
Attributo 1Attributo 2Attributo 3
Entità “client”Entità “client”
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 272272
Oggetto “Web Service”
“Metodo” 1“Metodo” 1
Server SOAPServer SOAP
Accesso diretto DB
Modulo del Sistema
Informativo
Modulo del Sistema
Informativo
Distribuzione messaggiRuolo del “centralino”
“Metodo” 2“Metodo” 2
“Metodo” 3“Metodo” 3
“Metodo” 4“Metodo” 4
Messaggio SOAP
API
RDBMS
137
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 273273
Oggetto “Web service client”
Creazione XML 1Creazione XML 1
Client SOAPClient SOAP
Modulo del Sistema
Informativo
Modulo del Sistema
Informativo
Creazione XML 2Creazione XML 2 Messaggio SOAP
al server
RDBMS
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 274274
Bibliografia: UML
M. FowlerUML distilled, 3rd edEd. Prentice Hall, 2003
L. Vetti TagliatiUML e Ingegneria del softwareEd. Mokabyte 2002http://www.mokabyte.it/umlbook/downlo
ad.htm
138
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 275275
Bibliografia: UML for business
H. Eriksson et M. PenkerBusiness Modeling with UMLEd. John Wiley & Sons., 2000
A.G. Nillson et al. Perspective on Business ModelingEd. Springer-Verlag, 1999
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 276276
Bibliografia Web
• OMG• http://www.omg.org
• Astrakan• http://www.astrakan.com
• Open Training• http://www.opentraining.com
139
Giulio DestriGiulio Destri -- © © EleusysEleusys for Univ. Parma, 2003for Univ. Parma, 2003UML UML nellanella progettazioneprogettazione SW SW -- 277277
Bibliografia Web
Documenti reperibili in rete presso• http://www.uml.org• http://www.mokabyte.it/umlbook/index.htm• http://www.ebxml.com• http://www.oasis-open.org• http://www.ibm.com• http://www.microsoft.com• http://www.iona.com