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'ENTITAe descritta sia dai messaggi e non dalle sequenze.

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

• LEGGIBILI
• COMPRENSIBILI
• VALDABILI

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

1. ATTORI
   • nome
   • Attore ≠ utente
2. CASO D'USO
   • Nome del caso d'uso
3. RELAZIONI
   • ATTORI generalizzazione: ereditarietà tra attori;associazione: partecipazione attori ad un caso d'uso.

FORNITORI, MANAGER, STUDENTI, ecc.SISTEMA INFORMATIVO, CONTABILIA...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
• valdabali

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.
   • fornitori, manager, studente, lettore...
   • sistema informativo contabile...
   • dispositivo hardware

   Attore ≠ utente

2. Caso d'uso

   Nome del caso d'uso

3. Relazioni
   • Attori ⇒ Generalizzazione: ereditarietà tra attori;
   • Attore vs caso d'uso ⇒ Associazione: partecipazione attori ad un caso d'uso.

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;}

questa a una piu specifica

CLASSE PIU GENERALE —> SUPERCLASSE

CLASSE SPECIALIZZATA —> SOTTOCLASSE

• DIPENDENZE —>
  1. FRIEND —> violare attributi indipendenti dalla visibilita
  2. USE —> richiede la presenza di un altro elemento
     • 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 potenzialita' di base del progetto.

1. ANALISI dettagliata 10-20% casi d'uso

2. ANALISI DEI REQUISITI ma funzionali piu' 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, capacita' e sicurezza
• Usability => Facilita' e fattori umani, help, documentazione
• Reliability => Gestione errori
• Performance => Tempo risposta e uso risorse
• Supportability => Capacita' di avviarsi su multilpeiaty, manutenzione e aggiornabilita'

+ => 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 certo

una visione complessiva del progetto derivite distorti e

vincoli di alto livello e di studio economico

2. SPECIFICHE SUPPLEMENTARI. Inserire i requisiti non funzionali,quelli raccolti nella categoria"URPS+". Altri requisiti funzionalima spesso precedentemente

3. STIMA DEI COSTI E DELLA TEMPISTICA. Stime importanti. Il fine è potermirare il budget per lo sviluppo/uso e stabilire il costo delsoftware.

Nel costo totale di un progetto di sviluppo software bisogna contibuoro.

1. COSTI HARDWARE - SOFTWARE - MANUTENZIONE
2. COSTI VIAGGI e FORMAZIONE
3. 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 publiccamente e principale e supportato da strumenti publici e commerciali. Integra diversi sottomodelli.Il sottomodello è quello del "MODELLO DI PROCESSIONENE INAREZIO"

FORMULA STANDARD:EFFORT = A * Size ^B * MA: 2,94Size: dimensioni del software in migliaia di righe di codiceB: expo che riflette lo sceso stimestoM: 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

1. Definire innanzitutto gli ATTORI
2. Per ogni attor occore individuare i CASI D'USO
3. 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 le t t i n i 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, puo visualizzare il prezzo complesso e proseguire con il pagamento attraverso sistemi certificati.

Se l'utente e stagionale, puo visualizzare la disponibilita' il prezzo delle cabina, suddiviso in pacchetti, pacche e cusolle. Puo affittare la cabina dipendendo numero identificativo e durata paccato, e se desidorato sospension dei servizi con costi.

Puo sapere se per ogni paccato paccheto affittato su un abballoncon cmomuto identificativo e costo appuntivo, puo 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, puo 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 puo rpesistance o puo eseguire il log-in.

RF2) L'utente puo visualizzare il calcolato.

RF3) L'utente puo pagato con sistimi artifaciti.

RF4) L'utente e occasionale puo visualizzare disponibilita e pacco abballoni.

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

RF6) L'utente se stagioniale puo visualizzare disponibilita e pacco dello cabiati.

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