Business Analysis II Analisi Tecnica Prof. Thimoty Barbieri Università degli Studi di Pavia
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Business Analysis II
Analisi Tecnica
Prof. Thimoty Barbieri
Università degli Studi di PaviaObiettivi del Corso
Mostrare una tecnica di riprogettazione dei processi
gestionali:
– Scelta della strategia informatica per il miglioramento degli indicatori
riscontrati
Mostrare come raccogliere i requisiti informativi e
Progettare il sw
– Utilizzo di tecniche standard dell’ingegneria del sw
Introdurre alla stima dei tempi e alla progettazione operativa
– Tecniche di dimensionamento
– Programmazione di Progetto
Presentare tecniche di realizzazione SOA – Oriented
– BPM / jBPM / BPEL
Business Analysis II 2 Thimoty BarbieriLaboratorio di analisi delle informazioni e
dei processi produttivi e logistici
Thimoty Barbieri
Indirizzo Logistico Produttivo
Analisi e Specifica dei Requisiti ITFlusso di lavoro di modellazione – Raccolta
Requisiti IT
Business Modeling
Business Process View
Business Structure View Process Class Business Behavior View
Diagrams Diagrams
State Activity Sequence
Organigrammi Diagrams Diagrams Diagrams
Assembly Lines
Descrizione in
Linguaggio Naturale
User View Use Case Diagrams
Piani di Collaudo
System Modeling
Structural View Behavioral View
Class Object State Activity Sequence
Diagrams Diagrams Diagrams Diagrams GUI
Diagrams
Business Analysis II 4 Thimoty BarbieriDefinizione dei Requisiti IT
La definizione dei requisiti IT si fa discendere dai diagrammi di
Assembly Line
I diagrammi di Assembly Line non sono uno standard UML, ma sono un
utile meccanismo per individuare entità candidate e casi d’uso candidati
Una volta derivati entità e casi candidati, essi vanno specificati e
modellati secondo le canoniche metodologie UML
La derivazione dalle Assembly Line è un processo di selezione di
alcune attività business, raccolte dentro uno o più casi d’uso
Business Analysis II 5 Thimoty BarbieriEntità Candidate
Le entità candidate rappresentano strutture dati o unità informative la
cui presenza si individua come significativa o probabile all’interno del
sistema IT di supporto. Le entità sono dette candidate perché solo una
successiva analisi più dettagliata dei requisiti determina se esse
“sopravviveranno”, evolveranno, o andranno ad inglobarsi con altre
entità
In generale una attività di business si svolge entrando in relazione di
lettura/scrittura (tabella CRUD) con più entità candidate.
Le assembly Line indicano graficamente i rapporti tra attività ed entità IT
mediante relazioni dirette di lettura e di scrittura
Business Analysis II 6 Thimoty BarbieriAssembly Line con Entità Candidate
Identificazione fabbisogni di produzione per i codici gestiti a scorta
Fabbisogni
Produzione
Fabbisogni Reparti
[codice in make]
Lordi in Pezzi Calcolo Capacità Necessaria Make
Make
Identificazione Previsioni Identificazione tipologia Identificazione Impegni
codice e Prenotazioni [codice in buy]
Calcolo Capacità Necessaria Buy Fabbisogni
Produzione
Entità Reparti Buy
Candidata Carica Previsioni Conferma Quote
Ordinate
Calcolo Capacità
Necessaria Make
Calcolo Capacità
Necessaria Buy
Imposta Previsioni
Calcola Fabbisogni
Lordi
Casi d’uso
Candidati
PREV (Previsioni Commerciale)
PC (Previsioni Cliente)
P (Prenotazioni)
I (Impegni)
Lettura
AA (Anagrafica Articoli)
DISTINTA (Distinta Base)
CICLI (Cicli Produzione)
Scrittura
FABB (Fabbisogni)
Business Analysis II 7 Thimoty BarbieriTabelle CRUD di rapporto attività/entità
Identificazione Identificazione Identificazione Calcolo Calcolo
Previsioni Tipologia Impegni e Capacità Capacità
Codice Previsioni Necessaria Necessaria
Buy Make
PREV CRU
PC R
P R
AA R R R
I CR
DISTINTA R R
CICLI R R
FABB C RU RU
Business Analysis II 8 Thimoty BarbieriCasi d’uso candidati
I casi d’uso candidati riguardano funzionalità del sistema,
che si svolgono mediante una serie di interazioni con le
entità candidate, rilevate durante le associazioni di
lettura/scrittura tra attività business ed entità candidate
Non è necessario che tutte le associazioni r/w ricadano
entro un caso d’uso candidato
Business Analysis II 9 Thimoty BarbieriCriteri di buona formazione AL
Questi criteri “preparano” il processo riprogettato per individuare con
precisione adeguata entità e casi d’uso candidati
Occorre che ciascuna attività business da cui discende la AL sia
“atomica”, cioè l’attore di business non possa pensare ulteriori
scomposizioni dell’attività
Gli output devono essere derivabili, a partire da tutti gli input che
entrano nel processo business modellato (es. se escono dei “materiali”
deve essere chiaro in che forma entrano)
Business Analysis II 10 Thimoty BarbieriLa raccolta dei requisiti IT
La derivazione da AL consente di raccogliere requisiti IT a partire dalla
riprogettazione del processo
Altri requisiti IT possono essere derivati dall’analisi di documentazione
IT esistente, documentazione organizzativa, moduli, rapporti, studio
delle funzionalità ERP correntemente utilizzate
L’utilizzo di prototipi software può essere utile per convalidare,
investigare o scoprire ulteriori requisiti insieme al committente
I requisiti evolvono durante lo sviluppo e la gestione di come essi
cambiano e impattano sul processo di sviluppo viene detto
Requirements Change Management.
Business Analysis II 11 Thimoty BarbieriRischio sui Requisiti
L’analisi del rischio sui requisiti identifica i requisiti che potrebbero
causare difficoltà nello sviluppo.
La valutazione della priorità è necessaria per permettere una semplice
taratura del progetto rispetto ai tempi
La valutazione della frequenza permette di individuare i casi d’uso più
“incisivi” nel funzionamento del sistema
La valutazione della criticità comprende una valutazione complessiva
riguardante importanza della funzione nel sistema, difficoltà di sviluppo,
complessità di implementazione
Business Analysis II 12 Thimoty BarbieriValutazione della criticità
La criticità può comprendere i seguenti fattori di rischio:
– Rischio Tecnico, difficoltà di implementazione a livello tecnico
– Rischio Prestazionale, se un requisito implementato può far diminuire in
modo non accettabile il tempo di risposta del sistema
– Rischio di sicurezza, se l’implementazione del requisito espone il sistema a
problematiche di sicurezza
– Rischio Integrità Dati, se l’impl. Req. Può causare inconsistenza nei dati, e
questo è difficile da riscontrare
– Rischio Sviluppo, se l’impl. Richiede l’uso di strumenti di sviluppo non
convenzionale o di cui si ha limitata esperienza
– Rischio Politico, quando parte della committenza o del team di sviluppo è
contraria all’implementazione del requisito
– Rischio legale, quando un requisito potrebbe violare leggi attualmente in
vigore
– Rischio di volatilità, quando il requisito è particolarmente soggetto ad essere
modificato
Business Analysis II 13 Thimoty BarbieriRequirements Management
La gestione dei requisiti riguarda tre punti principali:
– Identificare, classificare, organizzare e documentare i requisiti
– Gestire le modifiche dei requisiti (proposta, negoziazione con il
committente/implementatore, validazione, documentazione)
– Tracciabilità dei requisiti (mutue relazioni tra requisiti e come uno
dipenda dall’altro)
Business Analysis II 14 Thimoty BarbieriIdentificazione e Classificazione Requisiti
I requisiti sono descritti principalmente mediante asserzioni
in linguaggio naturale
I requisiti devono essere numerati seguendo uno schema:
– Numerazione generata in base alla struttura del documento dei
requisiti
– Numerazione sequenziale rispetto alla categoria del requisito,
eventualmente corredata da una etichetta mnemonica che ne
identifica la categoria di appartenenza
– Identificatore unico generato da un database dei requisiti
(compilazione dei requisiti guidata da uno strumento CASE)
Business Analysis II 15 Thimoty BarbieriGerarchie di requisiti
I requisiti possono essere strutturati gerarchicamente (un
requisito può essere composto da sotto-requisiti). La
suddivisione corrisponde a livelli diversi di
astrazione/dettaglio
A ciascun livello di specifica dei requisiti è possibile
associare un caso d’uso UML ed illustrarre la relazione tra
requisiti e attori mediante diagrammi dei casi d’uso.
Business Analysis II 16 Thimoty BarbieriEsempio di Requisiti
CU 3: INSERIMENTO CONFERMA D’ORDINE/ORDINE
[CU3.1] Il commerciale riceve da un cliente una conferma d’ordine o un ordine.
[CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente.
[CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo
temporale
[CU3.4] Il sistema evidenza se l’articolo viene prodotto in make oppure in buy
[CU3.5] Il sistema evidenza il prezzo standard dell’articolo e il tempo medio di realizzazione.
– [CU3.5.1] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal cliente, per un determinato articolo e
periodo temporale
[CU3.6] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente per un determinato
articolo.
– [CU3.6.1] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in
un impegno.
– [CU 3.6.2] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno.
Business Analysis II 17 Thimoty BarbieriDiagrammi dei Casi d’Uso
I diagrammi dei casi d’uso rappresentano i requisiti raccolti durante la derivazione dalle AL
Possono essere redatti a successivi livelli di astrazione (un caso d’uso astratto può
contenere gerarchicamente un diagramma dei casi d’uso più specifico).
Rappresentando i requisiti del sistema, si enfatizza cosa il sistema fa e chi fa che cosa
(attori)
Un caso d’uso richiede l’esecuzione di una computazione che avviene tramite interazione
tra le entità candidate individuate nelle AL
Le computazioni legate ad un caso d’uso possono essere specificate con diagrammi di
attività o di sequenza, in questi ultimi sono coinvolte le entità candidate.
I modelli dei casi d’uso, ed i relativi diagrammi dinamici di specifica sono sviluppati
iterativamente e parallelamente al diagramma statico delle classi (entità candidate)
Business Analysis II 18 Thimoty BarbieriModellazione Casi d’Uso
I requisiti testuali si mappano 1:1 con i casi d’uso dei diagrammi.
Nella ricerca dei casi d’uso occorre tenere presente che:
– Un caso d’uso modella una funzionalità completa (comprendente il
flusso principale di esecuzione, le sue deviazioni, e le condizioni di
eccezione
– Un caso d’uso è una funzionalità visibile esternamente all’utente e
come tale da esso percepita, interagendo con il sistema/software
– Ha un comportamento ortogonale rispetto ai comportamenti espressi
dagli altri casi d’uso (i casi d’uso possono condividere oggetti durante
l’esecuzione, ma ciascuna esecuzione è indipendente dalle altre)
– Un caso d’uso rappresenta una funzionalità che è sempre iniziata da un
attore (ma una volta iniziato, il caso d’uso può poi interagire con altri
attori); è possibile che un attore riceva semplicemente i risultati di un
caso d’uso iniziato da un altro attore
– Un caso d’uso è una funzionalità che produce sempre al termine
dell’esecuzione del singolo caso d’uso un risultato significativo e come
tale percepibile esternamente per un altro attore
Business Analysis II 19 Thimoty BarbieriRicerca dei Casi d’uso
E’ utile porsi queste domande, aiutandosi a rispondere dalla
mappatura derivante dalle AL:
– Quali sono le principali attività eseguite da ciascun attore?
– Un attore accede o modifica l’informazione nel sistema?
– Un attore informa il sistema su variazioni in altri sistemi?
– Un attore dovrebbe essere informato su modifiche avvenute nel
sistema?
Business Analysis II 20 Thimoty BarbieriDisegno del Diagramma Use Case
Lo stickman rappresenta lo stereotipo .
L’ovale rappresenta lo stereotipo di caso d’uso. Ciascun nome deve riflettere una
funzionalità del sistema secondo l’analisi dei requisiti.
La freccia di associazione determina se l’attore innesca il caso d’uso o ne subisce gli
effetti.
Venditore
Inserimento Ordine
Cliente
Convalida Ordine
Direttore
Business Analysis II 21 Thimoty BarbieriEsempio di Diagramma
Calcolo Capacità
Lordi
Calcolo Capacità
Necessaria Buy
Conferma Quote
Ordinate
Commerciale
Direttore Produzione
Carica Previsioni
Imposta Previsioni
Business Analysis II 22 Thimoty BarbieriStereotipi e Tipi di Associazione
I casi d’uso possono essere in relazione tra loro mediante particolari
associazioni:
– Associazione normale: stabiliste una comunicazione tra attore e caso d’uso
– Generalizzazione: permette a un caso d’uso specializzato la modifica o
l’estensione di un aspetto del caso d’uso di base
– Inclusione : specifica che un caso d’uso di base comprende
sistematicamente il comportamento descritto dal caso d’uso incluso. Il caso
d’uso incluso non è mai eseguito da solo ma solamente in quanto parte del
caso d’uso di base.
– Estensione : estende il comportamento del caso d’uso base
attivando un altro caso d’uso solamente in alcuni particolari casi (opzionali
nel regolare funzionamento del caso d’uso base)
– Utilizzo : specifica che un caso d’uso utilizza in parte o in tutto un
altro caso d’uso per il suo completamento
Business Analysis II 23 Thimoty BarbieriGeneralizzazione tra Attori
La generalizzazione tra attori consente di individuare
diverse categorie “di accesso” a determinate funzionalità.
I casi d’uso legati agli attori padri sono legati anche agli
attori figli, che possono avere associazioni aggiuntive
(specializzanti) ad altri casi d’uso.
Business Analysis II 24 Thimoty BarbieriSpecifica di un flusso di requisiti mediante
Activity Diagram
I diagrammi di attività possono essere utilizzati per chiarire i flussi con cui i
requisiti di dettaglio compongono un caso d’uso
Nel diagramma risulta anche semplice spiegare a chi compete una determinata
attività, e se questa attività sia innescata da un evento in ingresso, o produca un
determinato evento in uscita.
Nei diagrammi di attività vengono spesso indicati eventi in ingresso o in uscita
ad una sequenza di attività, ed elementi informativi di transito che evolvono
passando tra un’attività e l’altra di una sequenza.
Business Analysis II 25 Thimoty BarbieriDiagramma di
Cli ente Venditore Direttore
attività
Inseriment o
Ordine
Verifica Ordine
[ > 5000 Euro ]
[Finestra impegni vuota
Diagramma di
Seleziona Cliente
Attività
Visualizza Previsioni Venditore per Cliente
Visualizza Previsioni Cliente per Cliente
[dati da verificare rispetto a previsioni]
Inserimento Interrotto
[Ordine non previsto] [Conferma coincide con previsione]
Inserisci Conferma Ordine per Articolo per Cliente Conferma una Previsione come Impegno
Aggiorna Errore Previsionale per Inserimento Aggiorna Errore Previsionale
Impegno Inserito
Business Analysis II 27 Thimoty BarbieriSchema Documentale Completo di Specifica di
Caso d’Uso
Ogni caso d’uso individuato deve essere descritto utilizzando il
seguente schema:
– Attori: elenco di attori afferenti o efferenti al caso
– Breve Descrizione: una frase che sintetizza la natura del caso
– Flusso di Eventi: l’elenco numerato dei sottorequisiti che compongono il caso. I Flussi
Alternativi spiegano eventuali modalità alternative di esecuzione del caso.
– Pre Condizioni: una serie di asserzioni che devono essere verificate perché il caso
possa essere iniziato in esecuzione (si usa per stilare i piani di collaudo)
– Post Condizioni: una serie di asserzioni che devono essere verificate alla fine
dell’esecuzione del caso d’uso (si usa per stilare i piani di collaudo)
– Eccezioni: una serie di possibili errori che devono essere rilevati nel sistema, o di
eventi che possono causare una non lineare/corretta esecuzione del caso d’uso (si
usa per stilare i piani di collaudo)
– Frequenza Stimata di Utilizzo (si usa per decidere le priorità nel piano di sviluppo)
– Criticità (si usa per stimare il rischio legato al requisito)
Business Analysis II 28 Thimoty BarbieriEsempio di Specifica Caso d’Uso
1.1.1 [CU3]: Identificazione dei fabbisogni per codici a scorta :: Conferma Quote
Ordinate
1.1.1.3.2 Flussi Alternativi
1.1.1.1 Attori
Commerciale [CU3.10] Il commerciale decide di non inserire l’impegno perché
l’ordine è sensibilmente difforme alla previsione venditore.
1.1.1.2 Breve Descrizione [CU3.11] Il commerciale decide di non inserire l’impegno perché
l’ordine è sensibilmente difforme alla previsione cliente.
Questa funzione consente di visualizzare per cliente e articolo le previsioni di ordinativo, [CU3.12] Il commerciale decide di non inserire l’ordine perché il
inserire un ordinativo effettivo e confrontare la previsione con l’ordine effettivo. prezzo concordato è sensibilmente difforme al prezzo standard.
1.1.1.3 Flusso di Eventi
1.1.1.4 Pre Condizioni
1.1.1.3.1 Flusso Base Al commerciale perviene un ordine da trasformare in impegno.
[CU3.1] Il commerciale riceve da un cliente una conferma d’ordine o un ordine. 1.1.1.5 Post Condizioni
[CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. E’ stato inserito un impegno a fronte dell’ordinativo, oppure non si è in
[CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un alcun modo modificata la situazione precedente.
determinato articolo e periodo temporale
[CU3.4] Il sistema evidenza se l’articolo viene prodotto in make oppure in buy 1.1.1.6 Eccezioni
[CU3.5] Il sistema evidenza il prezzo standard dell’articolo e il tempo medio di Dati inseriti non validi
realizzazione.
[CU3.6] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal 1.1.1.7 Frequenza Stimata di Utilizzo (bassa, media, alta)
cliente, per un determinato articolo e periodo temporale
ALTA
[CU3.7] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente
per un determinato articolo.
[CU3.8] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di 1.1.1.8 Criticità (bassa, media, alta)
conferma e trasformare la previsione in un impegno. ALTA
[CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati
necessari e si crea un impegno.
Business Analysis II 29 Thimoty BarbieriProgettazione del Collaudo sui Requisiti
L’attività di collaudo è parte integrante del processo di sviluppo del software.
Il collaudo può essere considerato sotto tre punti di vista:
– Il collaudo è un’attività rivolta a valutare gli attributi o le capacità di un software o sistema, e di
determinare che esso risponda ai risultati richiesti.
– Il collaudo è il processo di eseguire un software o sistema con l’intento di trovarne dei difetti.
– Il collaudo è un processo con cui si esplora e si valuto lo stato dei vantaggi e dei rischi offerti da
un software e collegati al suo rilascio.
Le attività di collaudo avvengono in tutte le fasi di sviluppo del software/sistema.
Non è pensabile un’attività di sviluppo di successo per cui non siano pianificate adeguate
attività di collaudo.
Il collaudo di accettazione è il collaudo con cui si comprova presso il
committente la rispondenza alle specifiche dei requisiti
Business Analysis II 30 Thimoty BarbieriTipologie di Collaudo
Le fasi di collaudo corrispondono alle principali fasi dell’ideale
modello a cascata di sviluppo del software.
Regression Test
Business Analysis II 31 Thimoty BarbieriTipologie di Collaudo (2)
Unit Testing
– Detto anche “collaudo dei componenti” è una parte fondamentale del
processo di implementazione. Consiste nel scrivere software o realizzare
architetture di collaudo diretto del software. Uno dei principi cardini
dell’Xtreme Programming è lo scrivere i casi di test durante la scrittura
delle unità. Questo migliora anche l’architettura generale del software
perché questa tecnica richiede scrittura di codice altamente modulare
per consentirne la verificabilità automatica mediante attrezzature
(fixtures) di test. Lo unit testing riguarda il team di sviluppo e il
programmatore del componente. Il test dell’unità è studiato e realizzato
dal programmatore del componente.
Integration Testing/System Testing
– L’obiettivo del test di integrazione è assicurare che tutti i moduli
compresi nell’Applicazione Oggetto del Collaudo (AOC) si interfaccino e
interagiscano tra loro in modo stabile, corretto e coerente.
– Il test di integrazione riguarda solitamente il team di sviluppo. I test di
integrazione sono studiati dal progettista di sistema.
Business Analysis II 32 Thimoty BarbieriTipologie di Collaudo (3)
Acceptance Testing
– Lo scopo dell’Acceptance Testing è di confermare che il sistema soddisfi i
suoi requisiti di business, fornendo garanzie che il sistema funzioni
correttamente e sia utilizzabile prima di essere “consegnato” agli utenti.
– I test di accettazione sono stilati dagli analisti, sia del team di sviluppo che
del cliente, che redigono dei piani di test a partire dalla definizione dei
requisiti del sistema sviluppato.
Test di Regressione
– Lo scopo del test di regressione è fornire garanzie che AOC funzioni ancora
correttamente dopo le modifiche o le estensioni apportati al sistema o al
software.
– Non è propriamente una fase di test, ma una tecnica di test che viene
applicata trasversalmente ad ogni fase di test. Il test di regressione avviene
solitamente ripercorrendo i piani di test o i casi di test stilati per ogni fase,
per verificare che essi diano ancora esito positivo.
Business Analysis II 33 Thimoty BarbieriCriteri di Analisi per Scrittura di Piani di Collaudo
Il collaudo avviene seguendo dei “Piani”, elenco di attività di collaudo
che prevedono l’esecuzione di determinate operazioni, tipicamente la
prova delle funzionalità principali del sistema, sottoponendo opportune
collezioni di dati in input, a fronte delle quali ci si aspettano definite
collezioni di dati in output.
Compito dell’analista è individuare le funzionalità da testare, e quali
input ed output sono i più convenienti per verificare in modo efficiente
ed efficace le funzionalità del sistema
A questo fine esistono alcuni criteri guida di analisi del dato legato alla
funzione IT e business.
Business Analysis II 34 Thimoty BarbieriCriteri di Collaudo
I criteri di collaudo si possono suddividere in tre principali
gruppi:
– Criteri di Collaudo Generali
• Collaudo Positivo e Negativo
• Collaudo White Box e Black Box
• Intuizione dell’errore
• Collaudo software automatizzato
– Criteri di Collaudo Funzionali
• Partizionamento per Classi di Equivalenza
• Analisi al valor limite
• Collaudo Casuale
• Collaudo per transizione di stato
• Collaudo per funzione
Business Analysis II 35 Thimoty BarbieriCriteri di Collaudo (2)
– Criteri di Collaudo Non Funzionali
• Collaudo di Configurazione/Installazione
• Collaudo di compatibilità
• Collaudo di Ripristino da Guasto
• Collaudo di Prestazioni
• Collaudo di Affidabilità
• Collaudo di Carico
• Collaudo di Sicurezza
• Collaudo di Usabilità
Business Analysis II 36 Thimoty BarbieriCollaudo Positivo e Negativo
L’intento del collaudo positivo è verificare che un sistema risponda ai
suoi requisiti. I casi di test vengono sviluppati mediante analisi dei
requisiti di sistema, tipicamente attorno alle funzionalità cardine
comprese nel test di accettazione.
Il processo di collaudo negativo serve a dimostrare “che un sistema non
fa quello che non deve fare”. A questo scopo i casi di test sono
progettati per investigare il comportamento di AOC fuori dalle specifiche
dei requisiti. Il collaudo negativo viene spesso utilizzato per collaudare
aspetti di AOC che non sono stati documentati, o sono stati documentati
male o in modo incompleto nelle specifiche dei requisiti.
Business Analysis II 37 Thimoty BarbieriCollaudo per Transizione di Stato
L’analisi delle transizioni di stato parte da uno o più diagramma degli
stati UML, in cui si modellano i possibili stati in cui si trova il sistema, e
gli eventi che lo fanno transire, più le eventuali azioni contestuali alla
transizione.
L’analista disegna dei casi di test il cui scopo è attivare tutte le
transizioni tra uno stato e l’altro, specificando:
– Lo stato iniziale
– Gli input del sistema
– Gli output attesi
– Lo stato finale atteso
L’analisi della transizione degli stati solitamente produce casi di test di
tipo positivo o negativo.
Business Analysis II 38 Thimoty BarbieriEsempio
Specifica dei requisiti: Videoregistratore.
Il videoregistratore può trovarsi in uno di tre stati: standby, acceso, in riproduzione.
1. Quando si trova in standby, il videoregistratore può essere acceso premendo una
volta il pulsante standby (un indicatore luminoso passa da rosso a verde ad indicare che il
videoregistratore è acceso).
2. Quando il videoregistratore è acceso, può tornare in modo standby premendo il
pulante standby una volta (un indicatore luminoso passa da verde a rosso ad indicare che
il videoregistratore è in modo standby)
3. Quando il videoregistratore è acceso premendo il pulsante Play si riproduce la cassetta
correntemente inserita nell’apparecchio. Premendo il pulsante Stop quando il
videoregistratore sta riproducendo, causa l’arresto della riproduzione video.
Business Analysis II 39 Thimoty BarbieriEsempio
Casi di Test Positivi:
– Verificare che con il videoregistratore in standby, la
pressione del tasto standby causi il passaggio
dell’indicatore luminoso da rosso a verde e
l’accensione del videoregistratore.
– Verificare che con il videoregistratore in stato Standby
acceso, la pressione del tasto standby causa il
passaggio allo stato di standby e l’indicatore
luminoso passa da verde a rosso Standby Premuto / luce rossa
Standby Premuto / luce verde
Casi di test negativi:
– Determinare cosa succede se il tasto standby viene Acceso
premuto mentre il videoregistratore sta
riproducendo un nastro Play[ Videocassetta Caricata ] Stop
– Determinare cosa succede se il videoregistratore è
acceso e viene premuto il tasto play senza una In
Riproduzione
videocassetta caricata nell’unità
Business Analysis II 40 Thimoty BarbieriPartizionamento per Classi di Equivalenza
Il partizionamento per classi di equivalenza si basa sul fatto
che gli input e gli output della AOC si possono raggruppare
e suddividere in gruppi o classi, e che tutte le istanze di
queste classi sono trattate allo stesso modo dal
sistema/software.
Si assume dunque che testare un membro di ciascuna
classe equivalga a testarne tutti i membri.
Business Analysis II 41 Thimoty BarbieriEsempio
Un sistema informativo per la rendicontazione di missioni
dei commessi venditori prevede le seguenti specifiche per
la parte di sistema che registra le spese di tipo alberghiero:
– C’è un limite massimo di € 80 per la rendicontazione di spese
alberghiere, al giorno
– Qualsiasi registrazione che superi gli € 80 viene respinta e causa la
visualizzazione di un messaggio di errore
– Una registrazione deve essere > € 0 per essere registrata, in caso
contrario viene visualizzato un errore
Business Analysis II 42 Thimoty BarbieriEsempio
In questa specifica si partizionano gli input in tre categorie:
N. Caso Test Input Partizione Output
n. 1 50 0< valAnalisi al Valor limite
Si tratta di una tecnica collegata al partizionamento ai valori
limite, che si basa sullo stesso principio: il raggruppamento
in classi degli ingressi e delle uscite.
Mentre il partizionamento in classi prevede la scelta di un
valore rappresentativo per ogni partizione individuata,
l’analisi al valor limite si concentra sul collaudo utilizzando
valori scelti ai limiti delle partizioni. L’analista progetterà un
caso di test per ciascuno dei valori al limite delle partizioni,
oltre che per il valore all’ “interno”.
Business Analysis II 44 Thimoty BarbieriEsempio
Considerando la specifica del sistema di rendicontazione, si individuano due confini: -1,0,1 e 79,80,81.
Si possono aggiungere casi di test relativi ai seguenti valori limite:
N. Caso di Input Confine Output
Test
n. 4 -1 0 Errore
n. 5 0 0 Errore
n. 6 1 0 OK
n. 7 79 80 OK
n. 8 80 80 OK
n. 9 81 80 Errore
Business Analysis II 45 Thimoty BarbieriCollaudo per funzione
Viene utilizzato per collaudare le funzionalità business o la
business logic della AOC, nel modo con cui un utente o
operatore può interagire con il sistema durante il suo
normale uso.
Tipicamente corrisponde alla creazione di script di test che
ricalcano scenari di casi d’uso elaborati dalle specifiche dei
requisiti. Spesso questi script di test vengono raccolti in
moduli e fanno parte del Test di Accettazione.
Business Analysis II 46 Thimoty BarbieriEsempio di Piano di Test
Test Script (continuation sheet)
ID Progetto S.I.A. SITAL SPA – MAKE/BUY ENHANCEMENT
MAINTENANCE
ID Test Presenza di test CASO TEST UC3 – INSERIMENTO ORDINE/ORDINE CLIENTE
e codifica
derivata da struttura
Scopo del Test Verificare il funzionamento UC 3 ORDINE CLIENTE FLUSSO
requisiti
PRINCIPALE
Ambiente di Test Passi di test APPLICAZIONE SIA AVVIATA. UTENTE AUTENTICATO.
derivati da NESSUNA OPERAZIONE PRECEDENTE. FINESTRA
specifica requisiti INSERIMENTO ORDINE APERTA E VUOTA. FILE DI
DATABASE TEST_DB CARICATO SU MACCHINA DI TEST.
Passi del Test INSERIRE CODICE CLIENTE 005200. CONFERMARE
Dati di collaudo PREMENDO TASTO SX SU PULSANTE CERCA. SELEZIONE
derivati da analisi DELLA TERZA RIGA. INSERIMENTO DEL VALORE 20/03/03 IN
a classi equiv. CAMPO DATA IMPEGNO. INSERIMENTO 400 SU QTA
e valor limite PREVISTA. INSERIMENTO 15/04/03 SU DATA CONSEGNA.
INSERIMENTO 12.350,00 SU PREZZO. CHECKBOX
CONFERMA E AGGIORNA ATTIVE. PRESSIONE SU TASTO
INSERISCI.
Risultato Atteso Risultati derivati FINESTRA CONFERMA INSERIMENTO. CAMBIAMENTO DI
da specifica STATO DATABASE, TERZA RIGA PASSATA A STATO
CONFERMATO. CAMBIAMENTO NEL DATABASE ERRORE
requisiti o da analisi
PREVISIONALE DA 0,30 A 0,25.
collaudo negativa/positiva
Page of Pages
Business Analysis II 47 Thimoty BarbieriAssociazione tra piani di test e casi d’uso
Caso di test al Valore Limite Superiore
Periodicità Richiesta: 999
Stato superiore::Inserimento Anni
Data Chiamata: 01/01/03
Chiamata Importo Finanziamento:
Importo Richiesto: 9,999,999,999 €
9.999.999.999.999 €
Periodicità Finanziamento: 999 Anni
Stato superiore::Valutazione Pratica
Accettazione L’associazione tra piani di test e casi d’uso
Stato superiore::Flag Pratica
– Si utilizza per determinare i piani di test di casi
d’uso più importanti (utilizzando per la scelta
Deal Structurer
Stato superiore::Generazione Offerta dei test come criteri la priorità, la criticità e la
frequenza di ciascun caso d’uso, e inserendo
questi test nel piano di test di accettazione)
– Si può modellare con un’estensione del
diagramma dei casi d’uso
Business Analysis II 48 Thimoty BarbieriFlusso di lavoro di modellazione – Specifica
Requisiti IT
Business Modeling
Business Process View
Business Structure View Process Class Business Behavior View
Diagrams Diagrams
State Activity Sequence
Organigrammi Diagrams Diagrams Diagrams
Assembly Lines
Descrizione in
Linguaggio Naturale
User View Use Case Diagrams
Piani di Collaudo
System Modeling
Structural View Behavioral View
Class Object State Activity Sequence
Diagrams Diagrams Diagrams Diagrams GUI
Diagrams
Business Analysis II 49 Thimoty BarbieriLa Specifica dei Requisiti
La specifica dei requisiti è un’attività che prevede il
dettaglio, mediante modellazione dell’effettivo
funzionamento dei requisiti.
Il risultato dell’attività di analisi consente di specificare con
dettaglio la struttura dei requisiti di un caso d’uso (come
nell’esempio UC3 precedente)
L’attività di analisi consente inoltre di individuare tutte le
caratteristiche delle entità presenti nel sistema IT di
supporto
Business Analysis II 50 Thimoty BarbieriModellazione Statica delle Entità (Class Diagram)
L’individuazione delle entità/classi presenti nel sistema
parte da alcune linee guida di base:
– Si considerano le entità candidate evidenziate dall’analisi AL
– Ogni classe deve avere una chiara finalità nel sistema
– Ogni classe descrive uno “stampo” per un insieme di oggetti
– Ogni classe deve essere specificata tramite un insieme di attributi.
Determinare tra questi l’attributo di identificazione univoca (chiave).
Alcuni attributi complessi potrebbero diventare essi stessi Classi.
– Ogni classe comprende un insieme di operazioni. Le operazioni
costituiscono l’interfaccia della classe e sono espresse sotto forma
di segnature (parametri in ingresso e parametri in uscita).
Business Analysis II 51 Thimoty BarbieriClass Diagram
Ordine Cliente
Data : Date (from Use Case View)
Numero : int Nome : String
CodiceCliente : String +intestatario Cognome : String
Reparto : int Indirizzo : String
Approvato : boolean 0..* testata 1 BancaAppoggio : String
Citta : String
calcolaTotale() CAP : int
approva()
1
1..*
RigaOrdine Prodotto
Numero : int Codice : int
Sconto : float Descrizione : String
Quantità : int 0..* 1 Attivo : boolean
Business Analysis II 52 Thimoty BarbieriAssociazioni tra Classi
La ricerca delle associazioni è effetto dell’avvenuto censimento delle
classi. In questa fase si individuano gli attributi di classe e si decide
quali attributi non siano sufficientemente elementari, e quindi
costituiscano classi a sé, associate (o aggregate) con la classe di
provenienza.
Ulteriori associazioni si trovano immaginando di “eseguire” i casi d’uso
trovati: si stabiliscono infatti dei “canali di collaborazione” tra classe, che
si realizzano solitamente mediante associazione o mediante una
relazione di dipendenza (linea tratteggiata)
Business Analysis II 53 Thimoty BarbieriSpecifica delle Associazioni
Specificare un’associazione implica
– Assegnarle un nome
– Assegnare i nomi dei ruoli: sono usati per chiarire meglio
associazioni complesse, in particolare quelle ricorsive. Per
sceglierne i nomi ricordare che essi diventano il nome dell’attributo
nella classe posta al capo opposto della linea che rappresenta
l’associazione.
– Determinarne la molteplicità: vanno specificate per entrambi i
terminali (ruoli) dell’associazione. Se non evidenti, possono essere
omesse.
– L’aggregazione è trattata come un forma di associazione (nel caso
in cui l’associazioni implichi un concetto del tipo possiede in modo
esclusivo, possiede, ha, raggruppa)
Business Analysis II 54 Thimoty BarbieriGeneralizzazioni tra Classi
Le caratteristiche (attributi e operazioni) di una o più classi possono essere
astratte in una classe più generica (generalizzazione). La relazione di
generalizzazione è una connessione tra una classe generica (superclasse) e
classi più specifiche (sottoclassi). La generalizzazione permette l’ereditarietà
(riuso) delle caratteristiche nella superclasse da parte delle sottoclassi.
Oltre all’ereditarietà, la generalizzazione ha anche due altri obiettivi:
– Sostituibilità: l’oggetto di una sottoclasse è un valore ammesso per una
variabile sulla superclasse (ma non viceversa): ad esempio una variabile
Frutto accoglie come valore una istanza di Mela.
– Polimorfismo/Binding Dinamico: la stessa operazione ha implementazioni
differenti in classi distinte. Si usa spesso definendo operazioni astratte sulle
superclasse, per costringere le sottoclassi a fornire diverse implementazioni
operative.
Business Analysis II 55 Thimoty BarbieriEsempio
Ordine
Cliente idOrdine PortafoglioOrdini
pIva dataOrdine
ragioneSociale dataScadenza
1..* 1
aggiungiProdotto()
0
+rigaProdotto 1..*
Prodot to
gestisce Magazzino
1..* 1
riordina()
ProdottoPull ProdottoPush
riordina() riordina()
Business Analysis II 56 Thimoty BarbieriEsempio
Fabb
-codArticolo
-dataFabbisogno
-qtaFabbisogno
-lordaOrNetta
+calcolaFabbisognoArticolo() *
+calcolaFabbisognoLordoArticolo()
Distinta *
*
-codArticolo
* -codComponente
AA
-ncomp
*
Prev -codArticolo
Cliente
1 * -codCliente -erroreMedioPrevisionale *
-codCliente
-codArticolo -codDistinta
-ragioneSociale
-qtaPrev -codCiclo
-tipoPagamento
+inserisciPrevisione() 1 -makeOrBuy : bool
* -tipoArticolo
+prelevaPrevisione()
-tempoConsegnaDaBuy
Cicli
-prezzoStd
* -codMacchina
-tempoMedioProd
-codPasso
1 -codPassoSucc
Pc -codPassoPrec
-dataConsegna
-dataArrivoOrdine
+confermaPrevisione()
+prelevaPrevisioneCliente()
un impegno e' una previsione cliente
confermata, pertanto in fase di analisi
statica la rappresento come una Cicli Make Cicli Buy
PC generalizzata -repartoEsterno
I
-numImpegno
-prezzo
-dataConfermaImpegno
+inserisciImpegno()
Business Analysis II 57 Thimoty BarbieriAnalisi Dinamica dei Casi d’Uso nella Specifica
dei Requisiti
L’analisi dinamica per la specifica dei requisiti richiede l’utilizzo di
diagrammi di interazione: collaboration diagram e sequence
diagram.
I diagrammi di sequenza mostrano lo scambio di messaggi tra
oggetti, organizzato in una sequenza temporale. I diagrammi di
collaborazione enfatizzano le relazioni tra oggetti lungo cui i
messaggi sono scambiati.
Poiché i modelli di interazione fanno riferimento ad oggetti,
richiedono che sia stata completata almeno la prima iterazione nella
modellazione statica.
I modelli di iterazione non specificano esplicitamente il cambiamento
di stato degli oggetti (questo è modellato utilizzando i diagrammi di
stato)
Business Analysis II 58 Thimoty BarbieriDiagrammi di Sequenza
La ricerca delle sequenze dei messaggi segue i modelli delle attività. Le attività
di un diagramma sono associate a messaggi in un diagramma di sequenza. Se i
livello di astrazione usati tra activity diagram e sequence diagram sono simili,
questa corrispondenza risulta più semplice per l’analista.
Specificando i messaggi, si può distinguere tra segnali e chiamate. Un segnale
denota una comunicazione asincrona tra oggetti: il mittente può continuare la
propria esecuzione non appena inviato il segnale.
Una chiamata indica un’invocazione sincrona di un’operazione appartenente
alla classe ricevente la chiamata. Il messaggio di ritorno può contenere alcuni
valori destinati al chiamante, o semplicemente notificare l’avvenuta invocazione
dell’operazione.
L’analisi della sequenza porta alla scoperta di nuove operazioni nelle classi
individuate
Business Analysis II 59 Thimoty BarbieriDiagrammi di Sequenza
: Ordine : RigaOrdine : Prodott o :
: Cliente
BollaSpedizione
Inseriment o
Creazione Nuova Riga
Scelta Prodotto
Scelta Modalità Spedizione
Convalida Riga in Ordine
Conferma Inserimento Ordine
calcolaTotale( )
Business Analysis II 60 Thimoty BarbieriDiagrammi di Sequenza
Prev Pc I
FinestraCommerciale
apriFinestraImpegno()
prelevaPrevisione()
visualizzaPrevisione()
prelevaPrevisioneCliente()
visualizzaPrevisioneCliente()
inserisciConferma()
confermaPrevisione()
Business Analysis II 61 Thimoty BarbieriSpecifiche del Cambiamento di Stato
Lo stato di un oggetto in un certo istante di tempo è determinato dai valori dei
suoi attributi, inclusi gli attributi di relazione.
Mentre le specifiche dello stato definiscono gli attributi di una classe, le
specifiche del comportamento definiscono le operazioni di una classe, alcune
delle quali possono avere come effetto un cambiamento di stato.
Un diagramma a stati fornisce l’elenco degli stati possibili di un oggetto e delle
transizioni (legate ad operazioni) che causano il passaggio da uno stato all’altro
Il processo di ricerca degli stati di un oggetto è basato sull’analisi degli attributi
contenuti in una classe, e determinando quali attributi sono chiamati in causa
dai casi d’uso
L’analisi a stati può generare nuovi attributi con cui arricchire l’analisi statica
Business Analysis II 62 Thimoty BarbieriForma Generale di uno Stato Business Analysis II 63 Thimoty Barbieri
Diagramma Ordine non Inserito
di stato Richiesta Inserimento
Ordine
Vuoto
Inserimento Dati[ Cliente in Archivio ]
Ordine con
Testata
Annullamento
Inserimento Riga
Riga Annullata[ Righe < 1 ]
Inserimento Riga
Inizio Riga
Prodotto
Selezionato Quantità
Selezionata
Ordine Abortito
Consegna
Selezionata
Riga Completata
Inseriment o Riga
Riga Confermata
Ordine con
Riga Annullata[ Righe > 1 ] Annullamento
Riga
Salvataggio
Ordine
Salvato
Approvazione / Not ific a Responsabile
Ordine
Approvato
Ordine inserito
Business Analysis II 64 Thimoty BarbieriProgettazione della Base Dati
Praticamente la totalità dei S.I. si fonda su un database relazionale
(RDBMS).
L’analisi statica è il punto di partenza per individuare quali entità devono
essere “persistite”, in altre parole occorre tenerne una memorizzazione
persistente su un sistema di archiviazione e ripristino del dato (il database).
Altre entità invece sono funzionali solo all’esecuzione runtime del sistema.
Le entità con “persistenza” devono essere organizzate in tabelle (entità e
relazioni) all’interno di uno schema di database.
Solitamente lo schema strutturale della base dati prende la forma di un
diagramma E/R (entità e relazioni), da cui si deriva un tracciato logico ed
uno fisico. Il tracciato fisico viene direttamente utilizzato per la creazione
della struttura delle tabelle presenti nel database.
La realizzazione di questi tracciati è solitamente affidata ad esperti
progettisti di basi dati. L’analisi statica del class diagram è un prezioso
punto di partenza.
Business Analysis II 65 Thimoty BarbieriProgettazione dell’Interfaccia Grafica
(GUI)
Il progetto dell’interfaccia grafica tra utente e sistema (GUI) nasce con la
specifica dei requisiti. Il disegno della GUI consente di chiarificarsi
anche la sequenza dei requisiti nei vari casi d’uso. Requisiti e disegno
della GUI si arricchiscono iterativamente.
Nel progettare l’interfaccia si parte sempre dal principio che l’utente ha il
controllo non deve mai avere l’impressione di perderlo.
L’interazione con la GUI è sempre event-driven, si generano e si
raccolgono eventi a cui utente e oggetti reagiscono.
La GUI contribuisce alla prima impressione che ha l’utente del software,
pertanto deve essere gradevole da vedere, ordinata, coerente.
Business Analysis II 66 Thimoty BarbieriLinee guida per il disegno di GUI
L’utente ha il controllo
– Il programma non deve dare l’impressione di eseguire operazioni
“senza motivo” o fuori dal controllo dell’utente
– Nei momenti di attesa deve essere fornito all’utente un modo per
valutare cosa sta facendo il sistema (clessidra, barra di progresso…)
– Deve essere dato un feedback ad ogni azione dell’utente
– Deve essere dato un feedback ad ogni evento scatenato
internamente dal programma che debba essere notato dall’utente
Business Analysis II 67 Thimoty BarbieriLinee guida per il disegno di GUI
Consistenza
– Indica l’aderenza ad uno standard ed al moto consueto “di fare le
cose”. Ci sono due dimensioni di consistenza:
• Conformità agli standard tecnologici della piattaforma adottata (Windows
2000/XP, XWindow, MacOS X Aqua)
• Conformità di nomenclatura, codifica, e altre consuetudini sviluppate
internamente all’organizzazione che utilizza il sistema (standard interni)
– Adeguarsi agli standard è importantissimo per evitare di confondere
inutilmente gli utenti (che a priori sono già contrari a qualsiasi
innovazione costituita dall’ingresso in esercizio di un nuovo sistema
informatico)
Business Analysis II 68 Thimoty BarbieriLinee guida per il disegno di GUI
Personalizzazione e Configurazione
– La Gui deve consentire personalizzazione: cioè variazioni atte a
rendere più comodo l’utilizzo personale dell’utente, ad es.
ridimensionare colonne e finestre, cambiare i colori, ecc.
– Il sistema deve consentire la configurazione, in altre parole offrire
modi diversi di operare a seconda della tipologia di utente (ad es.
diversa complessità di finestre, localizzazione della lingua,
attivazione o disattivazione di messaggi di aiuto più o meno
dettagliati/invadenti)
Business Analysis II 69 Thimoty BarbieriLinee guida per il disegno di GUI
Tolleranza e Guida
– Una buona interfaccia tollera che gli utenti provino, commettano
errori, prendano strade errate, e se necessario consentono di
tornare indietro di uno o più passi, o al punto iniziale. Le Gui
tolleranti mettono a disposizione operazioni di annullamento, di
modifica e di ripristino a più livelli.
– Le operazioni di inserimento possono essere assistite
(autocompletamento) e i dati verificati (ad es. la / delle date viene
inserita automaticamente, date errate sono rifiutate dal sistema)
Business Analysis II 70 Thimoty BarbieriLinee guida per il disegno di GUI
Retroazione
– Quando il controllo è temporaneamente in mano al programma
l’utente deve sapere cosa sta accadendo: il sistema fornisce sempre
informazioni audio/visive sul proprio stato di esecuzione:
– Cursore con clessidra, messaggi di attesa, barre di avanzamento,
etc.
Business Analysis II 71 Thimoty BarbieriLinee guida per il disegno di GUI
Estetica e usabilità
– Occorre tenere presente l’estetica e l’ordine della GUI
• I campi devono essere disposti ben in colonna
• I pulsanti raggruppati in buon ordine
• Le etichette e i testi devono essere scritti correttamente e in buona
lingua
• Devono essere forniti suggerimenti interattivi (tool tip)
• In generale la semplicità nella costruzione è la migliore garanzia di
estetica ed usabilità in una interfaccia GUI
Business Analysis II 72 Thimoty BarbieriComponenti Base della GUI
La form è l’unità base di progettazione della GUI: la raccolta di eventi e
di dati avviene mediante una finestra.
Dedicare una Form per ogni funzionalità generale base del sistema.
Decidere
Se possibile
Decidere Immettere il titolo qui
AB chiudere,
Titolo C
minimizzare…
Form
Considerare
Pulsanti
Strumenti Per Prevedere
Operazioni Più Spazio Per
Frequenti Input e Output
Fornire
Dati, Controllo
Feedback
operazioni
Con Cursore
Comunicare
Campo stato
Stato Finestra
con Barra di
Stato
Business Analysis II 73 Thimoty BarbieriComponenti Base della GUI
z Il menu a tendina è uno dei modi più usati per raccogliere
funzionalità principali in più categorie.
z Solitamente si usa solamente nella form principale di ingresso
generale a tutte le funzionalità.
z Di solito per una voce di menu si apre una relativa form di
funzione.
Nome menu Nome menu Nome menu Nome menu
Voce di menu
Voce di menu
Voce di menu
Voce di menu Voce di menu
Voce di menu
z I pulsanti servono a eseguire una singola azione.
Annulla Esegui
Business Analysis II 74 Thimoty BarbieriComponenti Base della GUI
Le form contengono vari elementi base per la raccolta degli input: dati
oppure particolari varianti di azioni che devono essere eseguite.
Label: testo fisso di
richiesta
Immettere il titolo qui
TextField: per l’immissione di testo/dati,
Label sempre accoppiato ad una label
Slider: per l’immissione approssimata
di valori numerici
Immettere il testo Checkbox: gruppi di
Opzione1 Spunta1
Spunta1
azioni non esclusive tra
Opzione2
Spunta1 loro
Opzione3
Ghosting: indica che l’opzione/funzione
Campo stato temporaneamente non è accessibile a
Radiobox: gruppi di Raggruppamento causa dello stato o degli input correnti
opzioni mutuamente Di opzioni
esclusive
Business Analysis II 75 Thimoty BarbieriComponenti Base della GUI
Testi complessi sono visualizzabili in aree di maggiori dimensioni
Vanno sempre corredate dalla possibilità di scorrere il testo,
aumentare/diminuire l’area visualizzata
Immettere il titolo qui
Scrollbars, possono essere messe in
orizzontale oppure verticale.
Sono legate sempre ad un’area con
contenuto.
Campo stato
Business Analysis II 76 Thimoty BarbieriComponenti Base della GUI
In alcuni casi è preferibile non consentire all’utente di digitare valori
liberi, ma di scegliere tra valori pre-esistenti o predefiniti.
Immettere il titolo qui
Lista: consente la
selezione multipla di più
valori (tasto ctrl o shift)
ComboBox a discesa: la parte superiore è un
campo editabile, ma si può scegliere tra una
lista
Campo stato
Business Analysis II 77 Thimoty BarbieriComponenti Base della GUI
z Per mantenere semplice una form (con un numero
contenuto di elementi) si può dividere la finestra in sotto
schede attivabili mediante la “linguetta” o “tab sheet”
Immettere il titolo qui
Selezionare e digitare Selezionare eFiglio
digitare Selezionare e digitare
Ciascun tab corrisponde
Ad una form sottostante
diversa
Campo stato
Business Analysis II 78 Thimoty BarbieriTipologie di Finestre
Finestra
visualiz-
zazione dati
tabellare (righe
e colonne)
Business Analysis II 79 Thimoty BarbieriTipologie di Finestre
Finestre
master/detail (la
selezione sul
dato nel
comparti-mento
superiore fa da
filtro per i dati
nei
compartimenti
inferiori)
Business Analysis II 80 Thimoty BarbieriTipologie di Finestre
Finestra
struttura
albero/dato
Business Analysis II 81 Thimoty BarbieriTipologie di Finestre
Finestra
inserimento
dati guidato,
con validazioni
Business Analysis II 82 Thimoty BarbieriTipologie di Finestre
Inserimento dati
guidato con uso di
combo box
Business Analysis II 83 Thimoty BarbieriTipologie di Finestre
Finestre di dialogo
A uno o due pulsanti (OK / Annulla)
Eventualmente con scelte ulteriori o possibilità di digitare brevi
informazioni e confermare (es. Login/Password)
Business Analysis II 84 Thimoty BarbieriTipologie di Finestre
Tipologia frame
principale
MDI/SDI
(Multiple/Single
Document
Interface)
Business Analysis II 85 Thimoty BarbieriDerivazione GUI da Requisiti
Inserimento Conferme Ordine
Ricerca Previsioni
Mese Finestra Articoli
Gruppo Codice 1 Articolo FG3400
Cliente CASTOR ELETTRODOMOTICA SPA Articolo in make Cerca Previsioni
Tipo Previsione Data Previsione Quantità Prevista Impegnato
INTERNA 05/02/03 350
CLIENTE 08/02/03 400
CLIENTE 10/03/03 400
Inserimento Impegno
Data Impegno 20/03/03
Conferma Impegno da Previsione Selezionata
400
Qta Prevista Aggiorna Errore Medio Previsionale per Articolo
Data Consegna 15/04/03
Prezzo 12.350,00
Inserisci Annulla
[Anno Corrente: 2003] Previsioni Caricate. 1 Previsione Commerciale Presente. 1 Previsione Cliente Presente.
Business Analysis II 86 Thimoty BarbieriPuoi anche leggere
