Ingegneria del software

Casi d'uso

È una sequenza di transazioni di un sistema. La descrizione del caso d'uso definisce cosa accade nel sistema. Un caso d'uso rappresenta una funzionalità fornita da un'entità e descritta sia dai messaggi e non dalle sequenze.

L'utilità è quella di fornire descrizioni di utilizzo del sistema che sono facilmente:

• Leggibili
• Comprensibili
• Validabili

Vengono identificati: a seconda delle parti interessate:

• Committente
• Utilizzatore
• Analista
• Manutentore
• Progettista

Per identificarli: assumere sempre il punto di vista dell'utilizzatore.

Si descrivono attraverso l'UML.

1. Attori
2. Nome
3. Attore ≠ utente
4. Caso d'uso
5. Nome del caso d'uso
6. Relazioni
7. Attori, generalizzazione: ereditarietà tra attori; associazione: partecipazione attori ad un caso d'uso.

Fornitori, manager, studenti, ecc.

Sistema informativo, contabilità...

Dispositivo hardware.

Casi d'uso

È una sequenza di transazioni di un sistema. La descrizione del caso d'uso definisce cosa accade nel sistema. Un caso d'uso rappresenta una funzionalità fornita da un'entità e descritta non dai messaggi e non dalle sequenze.

L'utilità è quella di fornire descrizioni di utilizzo del sistema che siano facilmente:

• Leggibili
• Comprensibili
• Validabili

Vengano identificati: a seconda della parte interessata:

• Committente
• Utilizzatore
• Analista
• Manutentore
• Progettista

Per identificarli bisogna assumere il punto di vista dell'utilizzatore. Si descrivono attraverso l'UML.

1. Attori: un ruolo o un insieme di ruoli, persone o cose, che interagiscono con il sistema.
2. Fornitori, manager, studente, lettore...
3. Sistema informativo contabile...
4. Dispositivo hardware
5. Attore ≠ utente
6. Caso d'uso
7. Nome del caso d'uso
8. Relazioni
9. Attori ⇒ Generalizzazione: ereditarietà tra attori;
10. Attore vs caso d'uso ⇒ Associazione: partecipazione attori ad un caso d'uso.

Relazioni tra casi d'uso

1. Estensione: caso d'uso può essere esteso da un altro.
2. Inclusione: caso d'uso base incorpora caso d'uso d'inclusione.
3. Generalizzazione: da caso generale a caso specifico.

Scenari di interazione

Ogni specifica istanza di un caso d'uso.

Possono essere:

• Base ⇒ caso d'uso, termine entro positivo e sviluppo lineare.
• Alternativi ⇒ dentro positivo con complicazioni, entro negativo.

Informazioni di base

1. Pre-condizioni ⇒ ciò che deve essere vero affinché inizi il caso d'uso.
2. Post-condizioni per successo ⇒ ciò che deve essere vero quando il caso d'uso termina con il risultato atteso.
3. Post-condizioni per fallimento ⇒ ciò che deve essere vero quando un caso d'uso termina senza risultato atteso.
4. Evento innescante ⇒ l'azione che avvia il caso d'uso.
5. Attore primario.
6. Relazioni.

Diagramma delle classi

È un grafico che fornisce una statistiche in termini di:

1. Classi.
2. Attributi.
3. Operazioni.
4. Relazioni classi: associazione, generalizzazione, dipendenza.

Associazione: connessione semantica tra classi che si tradotte in connessioni tra oggetti.

I ruoli forniscono modalità per ottenere la relazioni.

Implementazione

Uno a uno:

class A { private B associazione X; public associa; Pattern (B pattern); }

class B { private A associazione X; public associa; Pattern (A pattern); }

Uno a molti:

class A { private lista a_B; public agg; Oggetto (B mando); }

class B { private A associazione X; public associa Pattern; }

Uno a molti: associazione tra una classe A ed una classe B, diversità ma connessione necessità perlino a oggetto di Classe A la sua opposto, questa a una più specifica.

Classe più generale → superclasse.

Classe specializzata → sottoclasse.

Dipendenze

1. Friend → violare attributi indipendenti dalla visibilità.
2. Use → richiede la presenza di un altro elemento.
3. Call istanziate.

Processo unificato (UP)

L'UP è un processo iterativo, ovvero è organizzato in una serie di progetti brevi di lunghezza fissa detti iterazioni.

Ogni iterazione comprende le attività:

• Analisi dei requisiti.
• Progettazione.
• Implementazione.
• Test.

Il risultato di ogni iterazione è un sistema eseguibile, testato, integrato e parziale.

I vantaggi dell’UP sono:

• Affrontare le problematiche di rischio maggiore nelle iterazioni iniziali, che hanno un’architettura poco.
• Gestire requisiti, richieste e cambiamenti pressoché ad ogni.
• Verificare continuamente la qualità.

Fasi dell’UP

1. Ideazione: visione approssimata, studio economico, portata, obiettivi, costi e tempi.
2. Elaborazione: visione raffinata, implementazione iterativa, modellazione, identificazione requisiti e stime realistici.
3. Costruzione: implementazione elementi rimanenti, preparativi al rilascio.
4. Transizione: Beta test e rilascio.

2. L'azienda permette di stabilire fini vision comuni e le potenzialità di base del progetto.

1. Analisi dettagliata 10-20% casi d'uso.
2. Analisi dei requisiti ma funzionali più critici.
3. Creazione studio economico.
4. Preparazione ambiente di sviluppo.

Analisi dei requisiti

Requisiti sono le condizioni alle quali il sistema deve essere assog.

In UP requisiti sono divisi in categorie secondo il modello FURPS:

• Functionality ⇒ caratteristiche funzionali, capacità e sicurezza.
• Usability ⇒ facilità e fattori umani, help, documentazione.
• Reliability ⇒ gestione errori.
• Performance ⇒ tempo risposta e uso risorse.
• Supportability ⇒ capacità di avviarsi su multilpeiaty, manutenzione e aggiornabilità.
• + ⇒ requisiti secondari ⇒ implementazione, interfaccia, operativi, fisici, legali.

I requisiti si dividono in: funzionali e non funzionali.

UP offre diversi elaborati dei requisiti, che sono opzionali, e solous quelli che appoggiano elaboro al progetto.

Gli elaborati principali sono:

1. Visione: viene riccita luce prime sorde di talcol elaborato certouna visione complessiva del progetto derivite distorti evincoli di alto livello e di studio economico.
2. Specifiche supplementari. Inserire i requisiti non funzionali, quelli raccolti nella categoria "URPS+". Altri requisiti funzionali ma spesso precedentemente.
3. Stima dei costi e della tempistica. Stime importanti. Il fine è potermirare il budget per lo sviluppo/uso e stabilire il costo del software. Nel costo totale di un progetto di sviluppo software bisogna contibuoro.

• Costi hardware - software - manutenzione.
• Costi viaggi e formazione.
• Costi sforzo: costi: impiego; costi: imprudenti, scalamente, o free; costi: supporto staff, contabile, amministrativo, pus pul; costi di tat e tfr.

Le stime dei costi da realizzare fa parte del Cocomo. Questo è un modello ben documentato pubblicamente e principale e supportato da strumenti pubblici e commerciali. Integra diversi sottomodelli.

Il sottomodello è quello del "Modello di processionene inarezio".

Formula standard: effort = A * Size ^B * M.

A: 2,94.

Size: dimensioni del software in migliaia di righe di codice.

B: expo che riflette lo sceso stimesto.

M: moltiplicatore che di base con caratteristica che influenza lo stima.

Si può calcolare poi UFP influenzato da:

4. Piano delle fasi - Gantt: occorr valutare per ogni fase gli di già fare "giorni-uomo" necessari alla mise effettuate. Posso racconto il quello di rappresentare tali possibilità con un grafico a barre detto diagramma di Gantt.
5. Lista dei rischi e piano gestione rischi: importante è la previsione di sedia e prendere provvedimenti et per evitarteli.

• Rischi per progetto.
• Rischi per prodotto.
• Rischi economici.

Quindo bisogno prima individuare i rischi e raccomandamenti strategiche per gestril.

6. Modello dei casi d'uso: è il meccanismo per definire appunto funzioni e componententali.

• Definire innanzitutto gli attori.
• Per ogni attor occore individuare i casi d'uso.
• Descrive il tutto con il diagramma dei casi d'uso UML.

2. Fase elaborazione

L'elaborazione è la serie iniziale di iterazioni durante le quali viene:

• Verificata e proposta l'architettura software.
• Stabilizzata la maggior parte dei requisiti.
• I rischi maggiori sono attaccati e risolti.

1. C'è il raffronto delle "specifiche supplementari".
2. Modello di dominio: deve venire rappresentato attraverso diversi UML unite le classi concettuali dell'uso del sistema.
3. Modello di progetto: attraverso di UML descrive le prestazioni e le logiche.
4. Documento dell'architettura software: riassume gli aspetti principali dell'architettura e la risoluzione del progetto.
5. Modello dei dati: viene studiato l'insieme dei dati per fornire lo sviluppo indicato le entità e le relazioni connesse.

3. Fase costruzione

In questa fase gli elaborati nelle fasi precedenti servono utilizzati come input per la generazione del codice.

Vengono raffinati i modelli:

• Modello dati.
• Modello di progetto.

Successivamente definisce il modello di implementazione e l'effettivo codice sorgente che comporterà:

• Script SQL: per creazioni database e definizioni client.
• File XML: definisce interfaccia utente.

4. Fase transizione

È un grafo con nodi e archi in cui i nodi rappresentano gli stati di una classe e gli archi, direzionali, rappresentano le transizioni di stato.

Mostra il comportamento di una classe mediante gli stati che può assumere e le sue relazioni, cambiamenti di stato, al verificarsi di casi esterni, eventi.

Osservazioni

Ogni arco ha il nome dell'evento che provoca la transizione che esso rappresenta. Una transizione può essere controllata attraverso sue condizioni.

Stato: condizione che un oggetto ha nel corso della propria vita e di cui interagiscono attributi la quale un oggetto soddisfa delle condizioni effettive della vita, o alterazioni di alcuni eventi.

Elementi descrittivi di uno stato:

• Nome - Identificatore dello stato, obbligatorio.
• Variabili di stato - Attributi che descrivono lo stato. Qualche volta questi sono temporanei, opzionali.
• Sequenza di eventi che determinano lo stato.
• Condizioni che caratterizzano lo stato.

Evento: qualcosa che accade in uno stato. Un evento può essere solo un segnale di temporizzazione, altri eventi trasportano informazioni tra due processi.

Diagrammi di interazione

Interazione: specifica i dettagli della comunicazione che dovrebbe aver luogo per realizzare un particolare compito.

Diagramma di sequenza

Grafico che mostra un'interazione o una sequenza di interazioni tra due più oggetti, medianti uno specifico tempo delle azioni. I messaggi, le sequenze istanze di ogni caso d'uso tracciate.

Elementi:

• Tempo.
• Oggetti.
• Lifeline, periodo di vita degli oggetti.
• Costruzione dell'oggetto.
• Distruzione dell'oggetto.
• Messaggi: da un oggetto verso un altro oggetto; da un oggetto verso se stesso, auto-collega.
• Valore di ritorno di un messaggio.
• Iterazione.

Diagramma di collaborazione

Grafico che mostra o mappa collaborazioni, che contiene una mappa di ruolo. Ha diagrammi messaggi, eventi. Dalle istanze degli elementi voluti. Dalle collaborazioni di istanze, che insistono di sotto la collaborazione che occupa il luogo collaborare di istanze relazioni.

Elementi:

• Oggetti.
• Messaggi: da un oggetto verso un altro oggetto; da un oggetto verso se stesso, auto-collega.
• Numero di sequenza.
• Iterazione.

Diagramma delle componenti

Grafico che mostra le componenti e le relazioni di dipendenza tra di esse.

Componente: una parte del sistema che è sostituibile e modulica, che incapsula l'implementazione ed espone un insieme di interface.

Diagramma di configurazione

Grafico che mostra la configurazione degli elementi attivi a runtime. Le componenti software, i processi, gli oggetti che li costituiscono e costituito da nodi che corrispondono ad una risorsa computazionale possono contenere istanzie di componenti e/o oggetti che eseguono. Le dipendenze di comunicazione e/o piacciono nodo/icone mia obiezione che indebito uso.

Traccia 21/04/17

Lido → affittare cabine.

• Piccole.
• Medie.
• Grandi.

Tempo di affitto → minimo 1 giorno e per più giorni consecutivi.

Cabine piccole stesso costo giornaliero → con numero.

Cabine medie stesso costo giornaliero.

Cabine grandi stesso costo giornaliero.

Bisogna tenere traccia degli affitti.

Chi usa la cabina ha:

• Acqua.
• Elettricità.
• Asciugamani.

Stesso costo per pacchi.

L'attività di servizi deve essere comunicata prima, con diverse pos.

Ombrelloni con numero → affitto giornaliero.

Affitto 2 lettini con numero e prezzo per giorno.

2 tipi di clienti con dati anagrafici:

• Occasionali → solo ombrelloni.
• Stagionali → cabina più ombrelloni.

1. Dominio di interesse, requisiti funzionali e specifiche supplementari.
2. Diagramma dei casi d'uso.
3. Descrivere caso d'uso, tabella auto mensile per lo staff.
4. Diagramma casi concettuali.
5. Definire specifiche supplementari.

• Per visualizzare calendario.
• Visualizzare disponibilità cabine ed affitto.
• Disponibilità autovetture. Offrire, quindi, con supplemento il numero identificativo.
• Scopri al momento dell'affitto se vuola due lettini con costo aggiuntivo.
• Quando passa.
• Procedura con il pagamento tramite sistema certificati.
• Visualizzare disponibilità cabine e lettini, anche con supplemento se.
• Affittare cabina con numero identificativo scritto.
• Scopri se affittare autovetture con costo aggiuntivo, e nel corso si affitta lettino con costo aggiuntivo.
• Visualizzare orario.
• Papamento sistemi certificati.
• Admin: visualizzare calendario.
• Visualizza il numero delle cabine, autovetture, lettini.
• Affitto e quantità.
• Visualizzare cliente tra plurali.
• Visualizza somma richiesto.

Sistema: notifica avvento papamento all'utente.

Emissione fatture periodicamente.

Permetti l'annullamento prenotazione entro tot h e notifica la continuazione del cliente.

Paralizza modifiche dei dati da effettare.

Analisi del dominio

Fase di ideazione, elaborato, visivo.

Il sw sviluppa con la migliore tecnologia portabile un software distribuito con un architettura client-server per la gestione di un lido.

Il software permette all'utente di registrarsi o loggarsi come utente occasionale o giornaliero. L'utente può visualizzare il calendario.

Se l'utente è occasionale, può visualizzare la disponibilità degli autovetture con il loro prezzo di affitto per affittarli e subabiliare scagliendo il numero identificativo e ricevere se per un costo appuntivo fisso prendere 2 lettini, può visualizzare il prezzo complesso e proseguire con il pagamento attraverso sistemi certificati.

Se l'utente è stagionale, può visualizzare la disponibilità il prezzo delle cabina, suddiviso in pacchetti, pacche e cusolle. Può affittare la cabina dipendendo numero identificativo e durata paccato, e se desidorato sospension dei servizi con costi.

Può sapere se per ogni paccato paccheto affittato su un abballoncon cmomuto identificativo e costo appuntivo, può visualizzare lo storico per voleraizon e paccato con astum certificati.

L'amministratore e pacco visualizzare il caledarzio il numeroe la quantitda delle cabina dei lettini e dopo paccabello, affittato, può visualizzare lo storico chlueni stagionale e l'autente annuale.

L'utente notificio avento pagamento alll'utente, e cutti fatture e prenotazione, permette modifica dei servizi da affittare.

Requisiti funzionali

RF1) L'utente può rpesistance o può eseguire il log-in.

RF2) L'utente può visualizzare il calcolato.

RF3) L'utente può pagato con sistimi artifaciti.

RF4) L'utente è occasionale può visualizzare disponibilità e pacco abballoni.

RF5) L'utente è occasionale può affittare cabina e sceliere e scapiarre 2 lettino appuffaici e paccato appuntivo.

RF6) L'utente se stagioniale può visualizzare disponibilità e pacco dello cabiati.

RF7) L'utente in stagioniale può affittato cabina e scapiarre e affittare 2 lettini appufiuci a pacco appuffivoo e pacco appurativo.