1. Definizione di UML

3. Specificare

4. Visualizzare

5. Costruire

6. Documentare

8. sintassi: regole attraverso le quali gli elementi del linguaggio (parole) sono assemblate in espressioni (frasi).

10. quale linguaggio di modellazione utilizzare per descrivere il lavoro progettuale

12. Include una descrizione e sequenzializzazione di attività, documenti e modelli.

15. entità coinvolte

16. relazioni esistenti tra di loro

17. Esempio:

18. Diagrammi di flusso

19. UML

21. deve descrivere il sistema correttamente, completamente e senza ambiguità;

22. Consistenza:

23. le diverse viste devono completarsi vicendevolmente per formare un insieme coerente

24. Semplicità:

25. deve poter essere compreso, senza troppi problemi, da persone estranee al processo di modellazione;

26. Manutenibilità:

28. Dettagli di implementazione

29. Visualizzare

30. Un immagine è meglio di 100 parole

31. Costruire

32. Idee, pensieri

33. Documentare

35. sanità, finanza, TLC, aerospazio

36. indipendentemente dalla piattaforma

37. Sistema:

38. una singola organizzazione vista nella sua globalità (es. azienda)‏

39. una parte di un’organizzazione (es. divisione, oppure processo)‏

41. Alta coesione (omogeneità interna)‏

42. Information hiding (poco rumore nella comunicazione)‏

43. Basso accoppiamento (indipendenza da altri moduli)‏

45. Componenti riutilizzabili

46. Dividere la logica dall'interfaccia

50. Abbozzo (sketch)

51. Progetto (blueprint)

53. Documentazione, discussione e condivisione delle idee

54. Basso rigore formale

55. Selettività: focalizzazione solo su alcuni aspetti dell’applicazione

57. Alto rigore formale

58. Completezza

59. Forward e reverse engineering

61. Utilizzare diagrammi per generare codice

64. sotto l'egida dell'OMG (Object Management Group)

65. a partire dal contributo dei “Tre Amigos” (GradyBooch, Jim Rumbaugh e IvarJacobson)‏

67. Obiettivo: creare un sistema di gestione di un'architettura distribuita basati sul paradigma ad oggetti.

68. Standard più importanti proposti:

69. architettura CORBA

70. linguaggio di modellazione UML

72. SADT (StructuredAnalysis and DevelopmentTechnique)‏

73. DFD (Data Flow Diagram)‏

75. Jim Rumbaugh: ObjectModelingTechnique - OMT

77. Jacobson capo di Objectory che nel 1995 fu acquistata dalla Rational e nel 1995 UnifiedModelingLanguage v0.9

78. Booch e Rumbaugh e Jacobson crearono consorzio “UML Partners” e redassero UML v1.0

80. dicembre 1998: versione 1.2

81. Marzo 2000: versione 1.3

82. settembre 2001: versione 1.4

83. marzo 2003: versione 1.5

84. luglio 2005 : versione 2.0

85. agosto 2006: versione 2.1

87. Diagrammi UML

89. Strutturali: come è composto il sistema

90. Comportamentali: come interagisce sistema

92. Object diagram

93. Deployment diagram

94. Component diagram

95. Package diagram

96. Activity diagram

97. Use case diagram

98. Sequence diagram

99. Communication diagram

101. Object diagram

102. Deployment diagram

103. Component diagram

104. Package diagram

105. Activity diagram

106. Use case diagram

107. Sequence diagram

108. Collaboration diagram

109. State Machine diagram

110. Interaction Overview diagram

111. Composite Structure

115. Spesso si combina con le componenti software per mostrare dove sono distribuite (ComponentDiagram).

127. DiagramInterchangeSpecification

128. layout dello schema con strumenti diversi (xmi)‏

129. UML Infrastructure

130. definisce il core dell'uml, cioè il meta modello utilizzato

131. UML Superstructure

132. definizione formale degli elementi uml, utilizzata dai tool dei vendor e definisce in dettaglio i diagrammi utilizzati

133. ObjectConstraintLanguage (OCL)‏

135. E’ il padre di tutti gli elementi

136. Viene usato per formalizzare la notazione e definire le specifiche di linguaggio per il metamodel

137. Metamodel

138. Ogni oggetto del metamodel è una istanza dei concetti del meta-metamodel

139. Qui si descrivono astrazioni di modelli object-oriented e component-oriented

141. Qui si definiscono i domini, i problemi e le soluzioni di sistemi

142. Userobject

143. E’ composto da elementi che semplificano i modelli UML

146. Supporto alla creazione dei diagrammi e validazione

147. Ricerca tra i mille modelli creati

148. Generazione del codice

149. Supporto a diversi linguaggi di programmazione, DDL, DML

150. Reverse engineering

151. Supporto all'analisi partendo dal codice

152. UML 1.x – 2.x

154. Together (Borland)‏

155. Visio (Microsoft)‏

156. TAU (Telelogic)‏

157. Objecteering (Softeam)‏

158. Poseidon (Gentleware)‏

159. Enterprise Architect (Sparx Systems)‏

160. Magic Draw (No Magic)‏

161. ArgoUML (open source)‏

162. StarUML (open source)‏

163. UModel 2005 (Altova)‏

164. TAU Developer and TAU Architect (Telelogic)‏

165. Jude (open-source)‏

166. InnovatorAOX 2006 Object eXcellence (MID)‏

167. Real-time Studio(ARTiSAN)‏

168. OMONDO EclipseUML Studio (open source)‏

169. PathMATE (Pathfinder Solutions)‏

170. Metis with UML 2.0 Template (Computas)‏

171. Describe (Embarcadero)‏

172. I-Logix Rhapsody

173. MetaMatrix MetaBase Modeller (Tibco)‏

174. Java Studio Enterprise (Sun Microsystems)‏

175. Model-in-Action (Mia Software)‏

176. Pattern Weaver Ver. 2.0

178. Dove si colloca

180. Interno

181. Punto di vista del progettista, interessato agli aspetti architetturali

182. Esterno

183. Visto come una “black box”, di cui si può osservare solo il comportamento dall’esterno

185. Vista del progettista (interno)

186. All’interno vi sono dei componenti

187. Ogni componente svolge funzioni particolari

188. Ogni componente deve essere utilizzato correttamente e rispettare dei requisiti

189. Vista dell’utente (esterno)

190. Nel manuale c’è la descrizione di come può essere utilizzato

191. Come si inserisce una cassetta

192. Come si effettua il fermo immagine

194. Descrivono l’interazione tra attori e sistema, senza rivelare l’organizzazione interna del sistema

195. Sono espressi anche in forma testuale, comprensibile anche per i non “addetti ai lavori”

197. Nelle fasi iniziali della progettazione

198. Chiariscono cosa dovrà fare il sistema

199. Stabiliscono una base comune per la discussione con il committente

200. Fine - individuare ed analizzare i requisisti del sistema

201. A regime

202. Guidano l’intero processo di sviluppo

203. Rappresentano il punto di partenza per la progettazione del sistema

204. Definizione dell’architettura

205. Creazione dei modelli di analisi e disegno

206. Realizzazione del codice applicativo

207. Costituiscono il riferimento primario per dei test per la verifica di quanto prodotto

208. la definizione

209. la progettazione

211. E’ costituito dalla documentazione e dai diagrammi

212. La Documentazione

213. Descrive, in modo testuale, il Caso d’Uso

214. Costituisce l’elemento centrale di comunicazione tra tutte le parti in causa

215. Committente, Management, Gruppo di progetto

216. Guida la progettazione e la definizione dei Casi di Test

217. I Diagrammi

218. Ruolo complementare ma secondario

220. Sono le funzionalità che il sistema mette a disposizione dei suoi utilizzatori

221. Descrivono il sistema da un punto di vista esterno (black box)‏

223. Sono i soggetti (esterni) che interagiscono con il sistema tramite messaggi

224. Ogni attore corrisponde ad un insieme coerente di ruoli che i soggetti possono assumere interagendo con il sistema

225. Possono rappresentare

226. Esseri umani

227. Sistemi hardware o software

229. Contiene un insieme di casi d’uso riguardanti un particolare sistema

230. Descrive in modo completo gli utilizzi del sistema dall’esterno

231. Non rileva la struttura interna del sistema

233. Ha il significato di comunicazione

234. Ogni caso d’uso è collegato agli attori (uno o più)‏

236. È quello per il quale è stato pensato il caso d’uso

237. Ha un interesse primario per la funzionalità che quel caso d’uso esprime

238. Attore secondario

239. E’ un sistema esterno che interagisce con il sistema di riferimento nell’ambito del caso d’uso

240. Ogni caso d’uso ha per definizione almeno un attore primario

241. Il ruolo “primario” o “secondario” non è assoluto

242. Un attore primario per un caso d’uso può essere secondario in un altro

244. L’unica associazione ammessa tra attori è la specializzazione

245. L’attore specializzato eredita la partecipazione a tutti i casi d’uso con i quali comunica l’attore generico

247. Non è ammessa in UML una associazione di comunicazione tra i casi d’uso (un caso d’uso descrive un utilizzo completo del sistema)‏

249. Specializzazione

250. Estensione

252. Il caso d’uso specializzato può aggiungere nuovi passi o ridefinire i passi ereditati da quello generale

253. Ogni caso d’uso generale può avere più figli

255. La sequenza comune può essere esportata e definita come un caso d’uso a se stante

256. Il caso d’uso che si ripete verrà poi incluso in altri casi d’uso

257. In questo modo si evidenziano le parti in comune

259. L’estensione riguarda un comportamento opzionale del caso d’uso base (l’estensione è soggetta ad una condizione di attivazione)‏

260. La direzione dell’associazione di estensione va dal caso d’uso “di estensione” al caso d’uso “base”

261. L’estensione viene utilizzata tramite la parola chiave <<extend>>

263. Esempio

264. Esempio

266. Esempio – in un caso d’uso “Acquistare un prodotto”, ogni acquisto effettuato da uno specifico cliente in uno specifico momento costituisce uno scenario particolare

267. Ci sono due diverse tipologie di scenario

268. Scenari di successo (nell’esempio – l’acquisto va a buon fine)‏

270. l’interazione tra il sistema

271. gli attori coinvolti nello scenario

272. La prassi più diffusa per la specifica degli scenari consiste in:

273. definire uno scenario base, cioè lo scenario che porta al successo dei casi d’uso

274. definire gli scenari alternativi, cioè gli scenari che possono verificarsi per effetto delle varianti che possono condurre ad un nuovo scenario

276. dallo studio del manuale d’utente se disponibile

277. da suo utilizzo

278. tramite una serie di interviste agli utilizzatori

279. Per un sistema nuovo o per un sistema in evoluzione

280. dai requisiti già rilevati dal committente

282. Per ogni attore primario, rilevare in quale modo può/deve utilizzare il sistema, partendo dagli obiettivi che deve raggiungere.

283. Ad ogni modalità di utilizzo corrisponde, almeno inizialmente, un caso d’uso

284. Per ogni caso d’uso, descrivere

285. lo scenario base

286. la sequenza di passi più semplice possibile che conduce al successo del caso d’uso

287. le risposte attese dal sistema

288. le principali varianti a tale scenario

290. la tipologia del sistema di cui descrivere l’utilizzo

291. l’approccio utilizzato per la progettazione

292. Se il sistema cui ci si riferisce è un sistema software, la realizzazione dei casi d’uso dipende dall’approccio utilizzato per la progettazione

293. Object-oriented - La realizzazione comporta

294. l’individuazione: delle classi che vi parteciperanno, delle rispettive responsabilità

295. nonché la definizione delle modalità di interazione tra gli oggetti delle classi coinvolte

296. Strutturato-funzionale - Si devono definire

297. le procedure e le transazioni coinvolte

298. la struttura gerarchica dei moduli software

300. La collaborazione è costituita da una serie di oggetti che interagiscono tra di loro cioè effettuano delle azioni e si scambiano messaggi per richiedere servizi corrispondenti alle rispettive responsabilità

301. La collaborazione che realizza uno scenario può essere descritta

302. A livello statico, mediante un diagramma delle classi che evidenzi le classi o gli oggetti coinvolti nella collaborazione e le rispettive associazioni e legami

304. Dove si colloca

306. Rappresenta il sistema attraverso una visione statica

307. Rappresenta le classi che compongono il sistema ed i relativi attributi e comportamenti

309. Ogni classe è descritta da:

310. Nome della classe (l’identificatore)

311. Attributi (lo stato)‏

313. Regole importanti

314. Se una classe C ha un attributo A di tipo T, ogni oggetto che è istanza di C ha l’attributo A, con un valore associato di tipo T

318. modella una proprietà della classe

319. valida per tutte le istanze

321. ha vita propria

322. è identificato univocamente mediante l’identificativo di oggetto

323. è istanza di una classe (la classe più specifica)‏

324. DivComm è l'identificativo dell'oggetto

325. Libro è la classe di cui l'oggetto è istanza

327. per calcolare una proprietà,

328. per effettuare cambiamenti di stato

329. In una classe, un’operazione si definisce specificando i parametri e il tipo del risultato (se c’è).

332. (+) Pubblico: visibile da tutte le classi

333. (#) Protetto: visibile dalle classi dello stesso package o dalle sottoclassi

334. (~) Package: visibile solo dalle classi dello stesso package

336. Non può essere istanziata, ma può avere costruttori.

337. Può contenere sia dei metodi astratti (statici e di istanza) sia dei metodi concreti

338. Se un metodo è definito astratto, anche la classe deve essere astratta,

340. E’ possibile inserire il costruttore (non astratto)

341. I metodi statici sono sottolineati

342. Il metodi astratti sono in corsivo

345. Classe Astratta

346. Classe Astratta public class Sfera { double raggio; public Sfera(double raggio, double ps) { this.raggio = raggio; pesoSpecifico = ps; } public double volume() { return 4/3 * Math.PI * Math.pow(raggio,3); } } public class Cubo { double lato; public Cubo(double lato, double ps) { this.lato = lato; pesoSpecifico = ps; } public double volume() { return Math.pow(lato,3); } } public abstract class Solido { double pesoSpecifico; public abstract double volume(); // metodoastratto public double peso (){ return volume() * pesoSpecifico; } }

347. Classe Astratta

348. Classe Astratta class MiaAvvio { public static void main(String[] args) { ClassAbstract ca = new Classe(); } } Cosa succede invece in questo caso? abstractclassClassAbstract { public ClassAbstract(){ System.out.println("ClassAbstract"); }; } classClasseextendsClassAbstract { public Classe(){ System.out.println("Classe"); }; }

349. Classe Astratta class MiaAvvio { public static void main(String[] args) { ClassAbstract ca = new Classe(); ca.metodo(); } } Ed in questo caso? abstractclassClassAbstract { public void metodo(){ System.out.println("metodo ClassAbstract "); }; } class Classe extendsClassAbstract { public void metodo(){ System.out.println("metodo Classe"); }; }

350. Classe Astratta class MiaAvvio { public static void main(String[] args) { ClassAbstract ca = new Classe(); ca.metodo(); } } Ed in questo caso? abstractclassClassAbstract { public void metodo(){ System.out.println("metodo ClassAbstract "); }; } class Classe extendsClassAbstract { public void metodo(){ super.metodo(); System.out.println("metodo Classe"); }; }

351. Classe Astratta class MiaAvvio { public static void main(String[] args) { ClassAbstract ca = new Classe(); ca.metodo(); } } Ed in questo caso? abstractclassClassAbstract { public abstractvoid metodo() } class Classe extendsClassAbstract { public void metodo(){ System.out.println("metodo Classe"); }; }

353. costanti

354. metodi d'istanza astratti

355. metodi e proprietà “public”

356. quindi non può contenere:

357. né costruttori

358. né variabili statiche

359. né variabili di istanza

360. né metodi statici

364. Uguale alla classe ma con indicato lo stereotipo <<interface>>

365. Con una icona a forma di pallina (lollipop -> “leccalecca”) puntata da una freccia tratteggiata (dipendenza)

368. Come le classi, le interfacce possono usare l’ereditarietà con altre interfacce

373. Aiutano a modellare sistemi complessi

374. Possono esistere package e sottopackage

375. Si tende ad inserire nel package classi che hanno un comportamento e scopo comune nel sistema

377. Tipicamente, tutte le classi identificate sono connesse con altre secondo precisi criteri

378. Non è sufficiente identificare le classi che compongono il sistema,

379. Ma è necessario individuare anche le eventuali relazioni che le legano

380. Nel mondo ObjectOriented, tutte le relazioni possono essere facilmente ricondotte ai tre tipi fondamentali

381. Dipendenza

382. Generalizzazione

385. Es. precedente

386. La dipendenza lega le classi “Window” alla classe ”Event”

387. Indica che un cambiamento di stato dell’oggetto “Event” genera un aggiornamento dell’oggetto “Window” che lo utilizza

390. accede ad un suo oggetti

391. invoca un suo metodo.

392. In tutti i casi esiste una evidente dipendenza tra le classi sebbene non ci sia un’esplicita associazione

393. Graficamente

395. Si nota come il metodo PlayOn necessita come parametro di un oggetto di tipo Channel

396. Ciò evidenzia una dipendenza tra le classi sebbene non esista un legame di associazione

398. Quando il riferimento ad un oggetto di una specifica classe venga fornito come parametro ad un metodo di un altro oggetto istanza di una classe diversa

400. Una classe figlio specializza il comportamento di quella del padre

401. Es. precedente

402. La generalizzazione lega le classi “Window” alla classe ”DialogBox”

404. È spesso indicata con la denominazione Is-kind-of (è di tipo), per specificare che un oggetto specializzato e “del tipo” dell’oggetto più generale

407. Un oggetto della classe Rectangle può essere sempre sostituito ad un oggetto Shape (non vale il contrario)

408. Un oggetto della classe Square può sempre sostituire sia da un’istanza della classe Rectangle sia da una classe Shape

409. Comprensibile se si considera che una classe figlio eredita proprietà e metodi della classe padre

412. Ciò implica che ogni riferimento a tale metodo, eseguito in un oggetto della classe figlio, farà riferimento al metodo ridefinito anziché a quello della classe padre

414. Linea piena con freccia vuota nella direzione della classe padre

418. Definire una nuova associazione R2 tra la classe C2 e la classeC3 (o una classe C4 che è sottoclasse di C3)

421. Incontrare entità aventi un comportamento o una struttura simile

422. Come agire

423. Modellare le varie entità attraverso classi distinte senza alcun legame

424. Estrapolare dalle entità il comportamento e la struttura comune, al fine di realizzare una classe più generale dalla quale far derivare tutte le altre

425. Può capitare di dover schematizzare determinate relazioni tra classi per mezzo di una relazione di ereditarietà multipla

426. nel caso in cui una classe figlio erediti da più classi padre

428. si può facilmente incorrere in errori qualora la classe figlio voglia ridefinire (override) la struttura e/o il comportamento di una delle classi padre

430. Prevede di rimpiazzare una ereditarietà “n-aria”, con

431. una singola relazione di generalizzazione

433. Un dipendente (Istanza della classe Equipaggio o Personale di terra) può essere un passeggero

438. 2-Relazione di generalizzazione

440. È una relazione strutturata tra classi che definisce un canale di comunicazione bi-direzionale fra le classi

441. Tra due classi è associazione binaria

442. Tra n classi è associazione “n-aria”

444. È anche possibile assegnare due nomi con i relativi versi alla stessa associazione

445. Osserviamo ancora che le frecce che simboleggiano il verso non aggiungono nulla al significato della associazione (che è sempre una relazione), ma aiutano ad interpretare il senso dei nomi scelti per l’associazione

449. Può sostituire il nome dell’associazione

450. Definisce un nome specifico per ogni ruolo che ha l’associazione con la classe

452. L’unico caso in cui il ruolo è obbligatorio è quello in cui l’associazione insiste più volte sulla stessa classe.

454. se la relazione è obbligatoria o no

456. Se le molteplicità di un attributo B di tipo T di una classe C non vengono indicate, vuol dire che B associa ad ogni istanza di C esattamente un valore di T

458. Un gruppo è formato da persone. Ogni persona può apparire in un gruppo al più una volta (ovviamente ciascuna persona può fare parte di 0, 1, molti gruppi) e non ha importanza indicare l’ordine di appartenenza

460. Una graduatoria ha un certo numero di posizioni ciascuna occupato da una sola persona (non consideriamo pari merito in questo esempio)e una persona può apparire un una graduatoria al più una volta.

462. Perché esistono molti link alla classe Studente in quanto lo stesso corso è seguito da molti studenti

463. L’attributo del voto non può essere messo nella classe Studente

465. Definisce una associazione del tipo “parte di”

466. Relazioni tra classi in cui: una rappresenta un oggetto (Whole) e l’altra una sua componente (Part)‏

467. È detta anche Whole-Part

468. E’ una associazione asimmetrica

469. Graficamente

472. La loro esistenza ha senso solo in relazione al contenitore

473. Creazione edistruzioneavvengono nel contenitore

474. I componenti non sono parti di altri oggetti

475. Se si cancella il contenitore si cancellano anche le parti

477. In UML gli stereotipi si mostrano aggiungendo il suo nome nel compartimento della classe racchiuso tra << >>

480. Riguardano la trasformazione degli eventi che accadono all’esterno e la notifica di cambiamento dello stato “presentation”

481. Dipendono dall’ambiente che circonda il sistema

482. Aiutano a comprendere i confini del sistema

483. Tipiche classi Boundary:

484. Finestre (interfacce utenti)

485. Interfacce verso stampanti

487. UserBoundary: classi che mediano la comunicazione con utenti umani del sistema

488. System Boundary: classi che mediano la comunicazione con altri sistemi

490. Crea, inizializza e cancella gli oggetti controllati

491. Controlla le sequenze o coordina l’esecuzione degli oggetti controllati

492. Rappresentano la dinamica del sistema mostrando come sono controllati i flussi di eventi

494. I valori dei suoi attributi sono in genere forniti da un attore

495. Il comportamento è indipendente dal contesto (attori)

496. Sono usate per rappresentare i concetti chiavi che sono gestiti dal sistema

499. Dove si colloca

501. Il SequenceDiagram illustra le interazioni degli oggetti ordinate in modo cronologico

502. Sono usati per “formalizzare” gli scenari, in termini di:

503. Entità (oggetti)‏

504. Messaggi scambiati (metodi)‏

506. La sequenza consuma del tempo per andare dall'inizio alla fine

507. Un SequenceDiagram contiene:

508. Oggetti

509. Graficamente – rettangoli con il nome sottolineato

510. Messaggi

511. Graficamente – tramite frecce a linea continua

512. Tempo

514. Rappresenta una singola entità

515. In un ambiente object–oriented rappresenta un'istanza

517. Rappresenta la comunicazione tra due oggetti

518. Va dalla lifeline di un oggetto alla lifeline di un altro oggetto

519. Tipi di messaggi

520. Semplice – trasferimento di controllo da un oggetto ad un altro

521. Sincrona – chi invia il messaggio deve attendere la risposta

522. Asincrona – chi invia il messaggio non deve attendere la risposta

524. In UML 1.x i messaggi sincrono ed asincroni erano visualizzati con una freccia con punta aperta completa o parziale,

525. In UML 2.x per evitare facili confusioni si è preferito visualizzarli con una freccia chiusa piena ed una aperta completa mantenendo sempre la linea continua

526. Sincrona

527. Asincrona

528. Il messaggio può essere inviato anche a se stesso in modo ricorsivoUML 1.x UML 2.x

530. Indica un messaggio inviate a se stesso

532. Indica uno stimolo di ritorno dopo l'invio di un messaggio

533. Non rappresenta un nuovo messaggio

534. Si commette l'errore di utilizzarlo ogni volta che si invia un nuovo messaggio

537. La X indica quando una particolare istanza cessa di esistere

538. Un oggetto può morire da solo o grazie all'invio di un messaggio da parte di un altro oggetto

543. Espresso tramiteconstraints

545. Lo stato viene valutato:

546. Se e’ verificato, allora possiamo continuare ad eseguire il SD

548. Pannello frontale: per il cliente

549. Registro del denaro: raccoglie le monete

550. Dispencer : dove viene erogato il prodotto al cliente

551. Funzionamento tipico della macchina:

552. Il cliente inserisce le monete nello slot

553. Il cliente fa la selezione

554. Le monete arrivano al registro

555. Il sistema controlla se il prodotto selezionato è nel dispenser

556. Il registro incrementa la sua riserva di cash

558. Dove si colloca

560. Sono semanticamente equivalenti in quanto mostrano stesso tipo di informazioni

561. Evidenziano le interazioni tra le parti

562. Rivolgono maggiore attenzione allo scambio dei messaggi

563. Ma è diverso dal SequenceDiagram:

564. Organizzato in funzione dello spazio e non del tempo

565. Non vi è una particolare dimensione per rappresentare il tempo a parte la numerazione.

567. Rappresentano una singola entità del diagramma

568. In un ambiente object-oriented rappresenta una istanza

569. Può rappresentare una particolare istanza di un oggetto o di un attore

570. I Link:

571. Label: mostra il messaggio

572. Frecce: puntano all'oggetto ricevente ed eseguono una delle operazioni dell'oggetto ricevente

574. Rappresenta la relazione tra gli oggetti in un particolare istante di tempo

575. E' una particolare istanza delle associazioni del ClassDiagram

576. Link a se stesso:

577. Rappresenta una particolare istanza di associazioni

578. Inizia e finisce nello stesso oggetto

580. Rappresenta la comunicazione tra due oggetti

581. La comunicazione può essere:

582. Sincrona

583. Asincrona

584. I messaggi vengono numerati per mostrare la sequenza temporale delle azioni

586. Spesso non è necessario descrivere il sistema utilizzando entrambi i diagrammi

587. Era possibile in UML 1.x passare da un SequenceDiagram ad un CollaborationDiagram e viceversa.

588. Un CommunicationDiagram, in UML 2.0, NON e’ più totalmente equivalente ad un SequenceDiagram.

590. State Machine Diagram

591. Dove si colloca

593. Specificano le sequenze di stati che ha un oggetto durante il suo ciclo di vita in risposta ad eventi.

594. Sono utili per mostrare il comportamento dinamico di oggetti particolarmente complessi

595. Graficamente è un grafo con vertici ed archi

596. Rappresenta il comportamento dei singoli oggetti di una classe in termini di:

597. Eventi a cui gli oggetti sono sensibili

598. Azioni prodotte

600. Gli InteractionDiagramssono usati per modellare il comportamento di diversi oggetti che cooperano mentre gli StatechartDiagramsvanno usati per modellare il comportamento di un singolo oggetto all’interno del suo ciclo di vita..

602. Possiede un numero finito di configurazioni

603. I transiti da una configurazione ad un altra sono in funzione di uno stimolo esterno

604. Descrivono il ciclo di vita degli oggetti di una classe, attraverso modifiche causate da eventi che li interessano

605. E’ composto da:

606. Stato

607. Attività/Azioni

608. Eventi

610. A run-time tutti gli oggetti possiedono uno stato

611. Lo stato di un oggetto è una condizione o situazione che si verifica durante il ciclo di vita dell'oggetto stesso

612. Rappresenta la situazione nel tempo di un oggetto che esegue una attività o aspetta qualche stimolo esterno

613. E' il risultato di tutte le attività eseguite fino a quel dato istante dall'oggetto

614. Lo stato è costituito dai valori associati ai relativi attributi e dai legami con altri oggetti

615. Uno stato perdura nel tempo finché un evento non fa cambiare stato all’oggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo)

617. Semplice

618. Uno stato che non contiene altri stati

619. Composite

620. Uno stato che contiene altri stati

621. Submachine

623. Rappresentano i punti iniziali e finali

625. Rappresentato con un rettangolo con gli angoli smussati

626. E’ composto da 2 compartimenti:

627. Nome

628. Una stringa testuale che distingue uno stato da un altro; se non ha nome è considerato anonimo

629. Transizioni interne

631. label

632. Identificano le circostanze sotto la quale l’azione specificata da action-expression viene invocata

633. Alcune label sono riservate:

634. Entry/Action: eseguita nel momento in cui si entra in uno stato

635. Exit/Action: eseguita nel momento in cui si esce da uno stato

636. Do/Activities: identifica un’attività in esecuzione mentre l’oggetto è nello stato della transizione

638. action-expression

639. Rappresentano operazioni interne eseguite mentre l’oggetto è in uno stato che possono richiedere tempo e sono interrompibili

640. Action:

641. sono delle attività che vengono subito eseguite

642. comportano un cambiamento di stato dell’oggetto

643. non possono essere interrotte altrimenti produrrebbero uno stato inconsistente

644. Activity:

645. sono dellea attività che vengono eseguite dopo che sono state eseguite altre attivita (entry, exit)

646. non comportano un cambiamento di stato dell’oggetto

649. Sono degli stati di astrazione che permettono di definire uno stato caratterizzato da determinate comportamento:

650. I tipi di pseudoStati sono i seguenti:

651. initial:

652. deepHistory

653. shallowHistory

654. join

655. fork

656. junction

657. choice

658. entryPoint

659. exitPoint

661. Join

663. Uno stato che ha sotto-stati viene detto stato composto

664. Può essere decomposto in

665. Sottostati sequenziali

666. Due o più sottostati concorrenti (dette regioni)

668. E' utile quando un oggetto ha diversi ed indipendenti comportamentali

669. Non bisogna esagerare con gli stati concorrenti

670. Se sono presenti numerosi stati concorrenti è utile dividere l'oggetto in parti più semplici

672. Se un sottostato concorrente raggiunge lo stato finale prima dell’altro, il controllo in questo sottostato aspetta nello stato finale

674. Rappresenta la relazione tra due differenti stati di un oggetto

675. Indica cha un oggetto che si trova nel primo stato (stato sorgente) eseguirà determinate azioni ed entrerà nel secondo stato (stato destinazione) quando avverrà un particolare evento e certe condizioni sono soddisfatte.

676. Ogni transizione potrà avere una etichetta

678. La Transizione è costituita da 5 parti:

679. Stato Sorgente: lo stato su cui la transizione agisce

680. Evento: lo stimolo esterno la cui ricezione da parte dell’oggetto nello stato sorgente rende la transizione candidata a scattare, in base alla condizione.

681. Condizione: una espressione booleana che viene valutata quando l’evento arriva. Se la condizione è verificata la transizione scatta

682. Azione: è atomica e non interrompibile. L’azione può essere costituita dall’invio di un evento ad un altro oggetto.

684. Verificarsi di un qualcosa degno di nota che può innescare una transizione di stato

685. Possono verificarsi 4 tipi di eventi:

686. Changeevent: L’evento si verifica quando il valore di una determinata condizione cambia da false a true (esempio “when (date = Jan. 1, 2004)” )

687. Timeevent: Il passare un determinato periodo di tempo (esempio “after (10 seconds)”)

688. Segnale: invio di un evento in modo asincrono

690. Espressione booleana che viene valutata alla ricezione dell’evento.

693. Un macro stato aiuta a comprendere meglio azioni comuni di tutti i sotto stati

695. Dove si colloca

697. Può essere usato in livelli di astrazione molto differenti

698. E’ un caso particolare di StatechartDiagram

699. Differenze

700. Supportano la descrizione di flussi paralleli

701. Transizione avviene in automatico quando l’attività è stata completamente eseguita

702. Non si necessita di specificare un evento esplicito che generi la transizione

704. Necessarie per realizzare le funzionalità del sistema

705. Semplice formalismo

706. Permette di rappresentare processi paralleli e la loro sincronizzazione

709. Un action state è uno stato con una entry action ed almeno una transizione uscente in corrispondenza del suo completamento.

710. Action state non ha transizioni interne, o esterne basate su eventi.

711. La transizione di uscita non avviene in corrispondenza di un particolare evento.

712. E’ uno stato in cui è in corso una specifica azione

713. Esempio:

714. Digitare un tasto

715. Eseguire una routine

717. E’ mostrata come una linea continua che va da un action state sorgente ad un action state di destinazione.

718. Rappresenta le relazioni tra differenti action state

720. Una swimlane è una regione che indica l’elemento responsabile degli actionstates dentro tale regione.

721. Indica chi sta eseguendo quella attività

723. rappresenta la selezione di una fra più transizioni sulla base di una condizione di controllo

724. Ha un solo punto di ingresso e molti di output

725. Solo un cammino di uscita può essere preso

727. Rappresentano l’evoluzione parallela del sistema

728. Ad una fork l’esecuzione prosegue parallelamente su due o più flussi figli

729. Ad una join I flussi figli si ricongiungono al flusso padre

730. L’esecuzione del flusso padre riprende solo quando l’ultimo dei flussi figli ha terminato

731. Fork ha un solo ingresso e più uscite

733. Utilizzate quando l’output di una action è causa di più esecuzioni di un’altra.

736. Le linee tratteggiate mostrano l’utilizzo di specifici oggetti nelle activity.

737. La linea che parte da una action indica l’oggetto in essa utilizzato.

739. Dove si colloca

741. Mostra l’organizzazione e le dipendenze dei vari componenti del sistema

743. i componenti sono moduli software (eseguibili o meno), dotati di identità e con un'interfaccia ben specificata

744. Non esiste un metodo unico per l’individuazione dei componenti (Alhir li definisce “una parte del sistema che esiste durante l’esecuzione del sistema”)

746. DeploymentComponent: costituiscono la base dei sistemi eseguibili (DLL, eseguibili, controlli ActiveX, Java Beans)‏

747. Work ProductComponent: sono ricavati i componenti del tipo precedente (file di dati e file sorgenti)‏

749. Rappresenta l’interfaccia di un componente

751. Tra due componenti esiste una dipendenza quando modificando la definizione di uno (il supplier) può doversi modificare la definizione dell’altro (detto client)

752. Tra classi esistono diversi motivi che causano dipendenza

753. comunicazione tra due classi

754. una classe memorizza i dati di un’altra classe

755. Una classe adopera i dati di un’altra come parametri

756. Mostra come il cambiamento di un componente causa il cambiamento di altri

758. UML consente di esprimere dipendenze tra tutti i suoi elementi, e in particolare nel componentdiagram

759. Una dipendenza viene rappresentata con una freccia tratteggiata (punta sul supplier), sulla quale è possibile indicare il tipo di dipendenza

761. Deployment Diagram

762. Dove si colloca

764. E’ utile quando si ha la necessità di mostrare componenti e oggetti in un sistema distribuito

766. Ogni nodo rappresenta una unità computazionale

767. Molte volte viene usato per rappresentare un componente hardware

768. Esempio:

769. Un semplice device

770. Un sensore

771. Un server

772. Un mainframe

774. In generale il nodo non rappresenta una specifica risorsa, ma una classe di risorse dello stesso tipo

775. Per rappresentare una specifica risorsa del sistema si usano le istanze di nodo

776. In un contesto object-oriented e’ analogo all’istanza di una classe

777. Una istanza di nodo e’ rappresentata come un nodo, ma il nome e’ del tipo nome:classe

779. Rappresenta il percorso di comunicazione tra più nodi

780. Può rappresentare il protocollo di comunicazione utilizzato

782. Tipicamente gli artifact sono file, e possono essere:

783. eseguibili (file .exe, .dll, script, file binari, ecc.)

784. Dati

785. file di configurazione

787. Un artifact può essere indicato elencandoli all’interno del nodo come class box all’interno del nodo, indicando però l’icona documento o la parola <<artifact>>

789. L’integrazione rappresenta la distribuzione dei vari componenti nei nodi del sistema