Dispensa in PDF - Dipartimento di Scienze Ambientali, Informatica e ...

More documents

Recommendations

Info

Carnielli Efrem: Programmazione a componenti Unified Software Process (USP) (comportamento): l'aspetto della macchina del sistema che utilizzo. Esempio: per accendere la macchina devo inserire la chiave, girandola innesco un meccanismo che provoca una scintilla che fa esplodere la miscela di aria e benzina all'interno del pistone... Di quest'ultimo gruppo fanno parte i diagrammi dei casi d'uso che ci apprestiamo a descrivere. 4.2.1.2 Use Case Diagram Gli use case diagram, o diagrammi dei casi d’uso, sono diagrammi che descrivono come viene percepito il comportamento di un sistema software da parte di un utente esterno. In sostanza esprimono il comportamento del sistema nei confronti dell'utente. Le funzionalità di un sistema vengono suddivise in transazioni (casi d’uso) utili per ciascuna delle classi di utilizzatori (attori). Questo strumento si adatta bene all’analisi dei requisiti in quanto il committente spiega le sue richieste tramite esempi, enumerando un certo numero di utilizzi. Il successo di questi diagrammi è dovuto al fatto che un'applicazione è tale perché viene utilizzata dall’utente e quindi l’analisi deve partire dall’interazione tra utente e sistema. Gli use case diagram si basano sul concetto di stereotipo, ovvero un qualcosa a cui viene associata una semantica generalizzata, accettata da tutti. UML offre una sintassi, alcune regole di composizione della sintassi e una blanda semantica (il significato della sintassi). Gli use case diagram hanno come componenti: • Attori: rappresentano le entità che interagiscono con il sistema (e non ne sono parte). • Casi d’uso: rappresentano l'interazione tra uno o più entità esterne e il sistema in esame. • Connessioni: relazioni che possono instaurarsi tra utenti e casi d'uso o tra casi d'uso e casi d'uso. 4.2.1.2.1 Attori L’attore è un ruolo che un'entità esterna impersona nei confronti del sistema in esame. L'entità esterna è tipicamente un utente ma può essere anche un altro sistema. Un attore sollecita il sistema con qualche evento e ne riceve un output. Un attore può interagire con il sistema per mezzo di una GUI (se è un utente), oppure attraverso un interfaccia application-to-application. Una medesima entità esterna può impersonificare più attori e viceversa lo stesso 76
Carnielli Efrem: Programmazione a componenti Unified Software Process (USP) attore può essere impersonificato da più entità. A seconda del ruolo dell’attore l’interazione col sistema è diversa. Per esempio ad un sistema aziendale possono accedere la segretaria oppure l’amministratore che si può comportare da segretaria; l’amministratore può svolgere le funzioni della segretaria nella stessa maniera o in un altro modo. La separazione dei ruoli può anche essere relativa all’esperienza che una persona può avere rispetto a un’altra. Un utente può essere contemporaneamente amministratore o fruitore del servizio. Può essere imposto che per accedere al sistema si debba scegliere una sola modalità oppure si possa rivestire simultaneamente più ambiti. Nel primo caso non ci sono problemi di contrasto tra ruoli, bisogna però gestire l’amministrazione di login. Nel secondo caso possono nascere problemi perché una stessa funzionalità può essere presentata in modi diversi e bisogna determinare quale utilizzare. Generalmente si sceglie la “più forte”, viene cioè data la priorità all’insieme più grande. Per esempio, nella visualizzazione di un bilancio aziendale: se fatta da un capo filiale viene visualizzato solo il bilancio della filiale, se fatta dall’amministratore generale viene visualizzato tutto il bilancio. L’amministratore può rivestire contemporaneamente la figura dell’amministratore e del capo filiale, perciò, in questo caso, l’insieme più forte è la visualizzazione del bilancio intero. L’attore nella notazione UML viene visualizzato in figura 4.1. Figura 4.1. Attore 4.2.1.2.2 Casi d’uso NA om ttore e attore Un caso d'uso è una tipica interazione tra una o più entità esterne ed il sistema in esame. Dal punto di vista del sistema un caso d'uso è la specifica di una sequenza di azioni (includendo anche le varianti) che il sistema in esame (o altre entità coinvolte) può eseguire interagendo con gli attori del sistema stesso. Possiamo dire che i casi d’uso descrivono il comportamento del sistema quando 77
Page 1 and 2:
Programmazione a componenti Dispens
Page 3 and 4:
Sommario Sommario Sommario 1 Progra
Page 5 and 6:
Carnielli Efrem: Programmazione a c
Page 7 and 8:
contiene sommariamente: • l'indir
Page 9 and 10:
Complilazione,linking… file.java
Page 11 and 12:
Macchina 1 Macchina 2 browser richi
Page 13 and 14:
owser R1 R2 Carnielli Efrem: Progra
Page 15 and 16:
elazione Entità 1 Entità 2 Figura
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
entità 1 entità 2 l. applicativo
Page 25 and 26: Carnielli Efrem: Programmazione a c
Page 27 and 28: Livello applicativo Livello di sist
Page 33 and 34: Figura 2.12. Intrasystem C/S Carnie
Page 35 and 36: 2.3 Terminal services Carnielli Efr
Page 37 and 38: Tty Emulator Sistema Operativo Hard
Page 43 and 44: Client Client Client Client Carniel
Page 45 and 46: Computer Client Figura 2.23. Applic
Page 47 and 48: Logica di presentazione (interfacci
Page 49 and 50: A A s; s; s=new s=new A(); A(); Car
Page 51 and 52: p 1 ret 1 y 3 p 2 ret 2 Stack di at
Page 53 and 54: g(){ . . . y = f(3, obj); . . . } f
Page 55 and 56: Activation record di h Activation r
Page 59 and 60: 3.1.4 Passaggio dei parametri Anali
Page 61 and 62: Figura 3.8. Chiamata di funzione Ca
Page 63 and 64: indirizzo. 3.1.5 Esempio: utilizzo
Page 65 and 66: 3.2.1 Riduzione del traffico di ret
Page 71 and 72: al momento della progettazione C/S.
Page 75: Carnielli Efrem: Programmazione a c
Page 79 and 80: Studente Carnielli Efrem: Programm
Page 81 and 82: Docente Figura 4.5. Extend Carniell
Page 83 and 84: I passi per la costruzione di un mo
Page 85 and 86: Studente Figura 4.7. Use Case diagr
Page 89 and 90: U te n te g e n e rico S tu d e n t
Page 95 and 96: Compila Scegli Questionario Present
Page 97 and 98: 4.2.1.3.1 Ancora sugli activity dia
Page 99 and 100: 4.2.1.4.1 L’ utente Carnielli Efr
Page 103 and 104: 4.2.1.4.4 Collocazione elementi a v
Page 105 and 106: seconda del tempo di attesa richies
Page 107 and 108: SOFTWARE HOUSE A Attore L’utilizz
Page 109 and 110: Analisi Progetto Test Sviluppo Fase
Page 113 and 114: Tabella 2. Relazioni RELAZIONE DESC
Page 125 and 126: Figura 4.38. Esempio di sequence di
Page 127 and 128:
• collaudo: eseguito con i veri u
Page 129 and 130:
Page 131 and 132:
C 1 Figura 5.5. Replicazione A C 2
Page 133 and 134:
Figura 5.7. Riorganizzazione. Carni
Page 135 and 136:
Page 137 and 138:
Client Client Client Carnielli Efre
Page 139 and 140:
6.3.4 Connessioni Carnielli Efrem:
Page 141 and 142:
sqlParziale sqlParziale = = “sele
Page 143 and 144:
Page 145 and 146:
Codice scritto con ling. di program
Page 147 and 148:
Client Carnielli Efrem: Programmaz
Page 149 and 150:
Module Language … … f() … …
Page 151 and 152:
6.9 Connessione al Database Server
Page 153 and 154:
Page 155 and 156:
posso utilizzare gli EJB indicati i
Page 157 and 158:
Page 159 and 160:
hgt utenti ____ nome ____ cognome _
Page 161 and 162:
Page 163 and 164:
Figura 6.18. OLAP a tre dimensioni.
Page 165 and 166:
Page 167 and 168:
Figura 7.4. Ereditarietà’ Carnie
Page 169 and 170:
Figura 7.6. B eredita dalla classe
Page 171 and 172:
• Interfacce dirette: fanno parte
Page 173 and 174:
op1 op2 op3 op1 op2 op3 op4 op5 Ca
Page 175 and 176:
Figura 7.11. B eredita dalla classe
Page 177 and 178:
int int perDue perDue (int (int (in
Page 179 and 180:
7.8.1 Diamond Inheritance Problem C
Page 181 and 182:
implementazioni. 7.8.2 Class compos
Page 183 and 184:
Page 185 and 186:
f() A Carnielli Efrem: Programmazio
Page 187 and 188:
Page 189 and 190:
8 Glossario / Appendice Carnielli E
show all

Dispensa in PDF - Dipartimento di Scienze Ambientali, Informatica e ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?