modellazione dei requisiti informativimb.unisalento.it/infoarchanddb/allegati/requirements.pdf ·...

Modellazione dei requisiti informativi


Un quadro di insieme

La modellazione della struttura

La modellazione del flusso

Le assembly lines

Requisiti e casi d’uso

3

PV-2007 - Gianmario Motta

La modellazione dei requisiti informativi

Dettaglio processo Assembly Lines

Use Case ER Diagram GUI diagrams

Modello strategico dei requisiti

Modello Processi

Struttura processoSwimlanes

CRUD grid

LRC gridModello ABE

4


MODELLAZIONE: ESTENSIONI UML ADOTTATE

(Business Extension UML)

Prodotto, consumabile, strumento tangibile o

intangibile ClassRisorsa

Aumento di conoscenza portato all’attività

(input) o derivato dall’attività (output)ClassInformazione

Indica una conclusione nel flusso (possono

essere molteplici). Tali conclusioni

costituiscono trigger potenziali di altri processi.

Signal Send (dinamico)

Class (statico)

Invio Evento Business

Rappresenta un trigger di attivazione (scadenza

od evento) Un flusso inizia con almeno un

trigger in ingresso

Signal Receipt (dinamico )

Class (statico)

Ricezione Evento

Business

Una attività elementare è una attività atomica

ed omogenea rispetto ad attore, frequenza,

luogo, procedura

Activity (dinamico)

Class (statico)

Business Activity

(Attività elementare)

Aggregazione di attività che soddisfano un

obiettivo (NB un processo può venire diviso in

processi)

Activity (dinamico)

Class (statico)

Business Process

DescrizioneSimboloStereotipo da UMLNome





Le assembly lines


6


MODELLAZIONE DELLA STRUTTURA (richiamo)

FormulazionePiano

CalcoloFabbisogno

Lordo

IndividuazioneFabbisogno

CalcoloPiano

Produzione

ConfermaOrdine

CalcoloFabbisogno

Netto

1

1

1

1

1

1

1

1

1

1

CalcoloPiano

ProduzioneUrgente

Associazioni fra processi :

-Composizione

- Specializzazione

7


D3 - Deliver Engineer-to-Order

Product

D3.11 - Invoice

Fatturazione

D3.3 - Enter Order,Commit Resources &

Launch Program

Immissione ordine, commisioneapprovvigionamenti e lancio

programmazione

D3.2 - Negotiate &Receive contract

Negoziazione ericezione del

contratto

D3.1 - Obtain &Respond to RFP/

RFQ

Procurarsi e risponderealle RFP/RFQ

Preparazione dell'offerta

"Budgetaria"

D - Deliver

D3.9 - Receive & VerifyProduct at Customer

Ricezione e verifica del prodottopresso il cliente

Invio offerta "Budgetaria"alle società di

ingegneria

Ricezione richiestedal cliente

D3.8 - Load Vehicle, Generate ShipDocs, Verify Credit & Ship Product

Carico veicoli, generazionedocumenti di trasporto, verifica

credito e trasporto prodotti

DIAGRAMMA DI STRUTTURA:

PERSONALIZZAZIONE SCOR (richiamo)





Le assembly lines


9



• Integra il modello strategico

definito precedentemente in

termini di organizzazione,

processo, fattori, IT

• Include

– Swimlane processi

– Flusso delle attività / swim-lanes

– Linear responsibility chart (LRC)

Proceso

Attvità

LRC grid

10


SWIMLANE : LIVELLO PROCESSO

G estione M ate ria li R epa rtoR espon sab ile P rodu z ione

C a lco lo P ro gram m aP roduz io ne

C a lco lo de i Fa bb isogn i

S caden zaP rogram m azione

S ettim an a le

C apac itàP rodu ttiva

A nagra fiche O rd in iL ive lloS corte

A nag ra ficheD is tin ta

B ase

P ro duz ionea Fabb isog no

P roposta d 'O rd ine

11


Resp. QualitàResp. Progr. e ProduzResp. VenditeVend. Uff. Marketing Dir. Vendite

Inviospecifiche

del progetto

Prezzopompa

Inputall'approvvigionamento

Acquisizionecommessa

Lancioprogrammazione

Fatturazione

Immissione ordine,commisione

approvvigionamenti elancio programmazione

Negoziazione e ricezione delcontratto

Procurarsi erispondere alle

RFP/RFQ

Ricezione everifica

del prodottopresso il cliente

OptionalPayment

ProductionPlans

Resourceavailability

RFQ/RFP

Sourcing plans

ReplenishmentSignal

Order Signal

ProductionSchedule

Delivery Plans

Order Backlog

OrderInformation

Payment

Carico veicoli,generazione documenti ditrasporto, verifica credito

e trasporto prodotti

Delivered EndItems

Shippingdocuments

Leggi diciascun paese Costi di

produzione

Informazionidel DB

aziendale

Tipologiapompa

Secondocontatto

della societàd'ingegneria

Accettazione/Rifiuto prodotto

Approved contract

Margine

calcolato

SWIMLANE : LIVELLO PROCESSO

12


SWIMLANE: LIVELLO ATTIVITA’ (caso sanità)

13


DealStructurer

Accettazione Prezzi SpedizioneCrediti Pratiche

Ricezione Chiam ata

Annotazione Modulo Accettazione

Chiamata

Modulo Accett

Imm issione Inform azioni

Verifica Fido

AccettVerificata

Personalizzazione Pratica

Pratica

Inserim ento e Calcolo Tasso

Pratica + Modulo

Tasso

Form ulazione Lettera Offerta

InvioOfferta

Concessione Credito

Richiesta Com plessa

Trattam ento Pratica

Richiesta Sem plice

<<benchm ark>>

Tempo elaborazione pratica: 90 m in

SWIMLANE: LIVELLO ATTIVITA’ (caso C-Credit)

14


Diagrammi di processo e di attività:

criteri di buona formazione: granularità

• La analisi va spinta a un opportuno livello di dettaglio, tale da

individuare attività elementari cioè non ulteriormente

scomponibili

• Una attività è elementare se è omogenea rispetto a:

– Attore

– Frequenza e/o evento attivatore

– Località (tipo di)

– Logica / procedura

15


Diagrammi di processo e di attività:

criteri di buona formazione : Precedenza

• Dati due insiemi informativi A e B, diciamo che B “precede” A, se A è ottenuto da B mediante un opportuno processo di elaborazione.

• Definiamo “operatore di precedenza” un operatore P tale che, applicato agli insiemi informativi del sistema, fornisce la corrispondente lista delle precedenze.

• Per esempio: P(A) = B,C,D indica che gli insiemi B, C, e D precedono l’insieme A. Si osservi che gli insiemi di input di una generica funzione elaborativa avranno liste delle precedenze vuote.

• Consideriamo ora un generico sistema informativo formato dagli insiemi A, B, C, D, E, e F, ed assumiamo la seguente lista di precedenze:– P(A) = B, C, D

– P(B) = E

– P(C) = E,F

– P(D) = F

– P(E) = 0

– P(F) = 0

• Gli insiemi E ed F sono l’input del sistema, mentre l’insieme A è l’output. Infatti, sostituendo ad A, B, C le rispettive precedenze, si ha P(A) = (E), (E, F), (F) che, semplificato, fornisce la lista degli input al sistema, consistente di E ed F.

16


LRC : OBIETTIVI

• OBIETTIVI

– Evidenziare i ruoli operativi + decisionali

– Buona formazione di ogni attività(orizzontale)

– Bilanciamento dei ruoli (verticale)

– Evitare sovrapposizioni : molte “E” sulla stessa riga

– Garantire uno e un solo punto decisionale: una sola D per riga

– Evidenziare chi riceve informazioni (I)

– Le etichette riportate sono indicative e possono essere specializzate o generalizzate secondo necessità

I-EIIEsecuzione

campagna

telefonica

IE-IIEsecuzione

campagna

negozi

---DEDefinizione

target

I--AEPianificazio

ne

campagne

Contr

ollo

gestio

ne

Rete

vend

ita

Con

tact

cent

er

Direzi

one

vendi

te

Mar

ketin

g

OrganizzazioneProcessi

17


LRC : ESEMPIO

I-EIIEsecuzione campagna

telefonica

IE-IIEsecuzione campagna

negozi

---DEDefinizione target

I--AEPianificazione campagne

Controllo

gestione

Rete venditaContact

center

Direzione

vendite

Marketing

OrganizzazioneProcessi

• E Esegue (notazione sempre presente)

• A Assiste & collabora in affiancamento a chi esegue

• D Decide (distinto da chi esegue od assiste)

• I Riceve informazioni




Le assembly lines


Casi d’uso e collaudo

19


Assembly Line : esempio 1

FabbisogniProduzioneReparti Buy

Calcolo Capacità Necessaria Buy

Identificazione PrevisioniIdentificazione Impegni

e Prenotazioni

Identificazione fabbisogni di produzione per i codici gestiti a scorta

Fabbisogni

Lordi in PezziIdentificazione tipologia

codice

Calcolo Capacità Necessaria Make

[codice in make]

[codice in buy]

FabbisogniProduzione

RepartiMake

PREV (Previsioni Commerciale)

FABB (Fabbisogni)

AA (Anagrafica Articoli)

CICLI (Cicli Produzione)

I (Impegni)

DISTINTA (Distinta Base)

P (Prenotazioni)

PC (Previsioni Cliente)

Carica Previsioni Conferma Quote

Ordinate

Calcola Fabbisogni

Lordi

Calcolo Capacità

Necessaria Make

Calcolo Capacità

Necessaria Buy

Imposta Previsioni

read

write

Candidate

EntityCasi d’uso

candidati

Attività indicate negli Activity Diagrams

20


Assembly line : note

• Le Assembly Line non sono uno standard UML, ma sono un utile

meccanismo per individuare entità candidate e casi d’uso candidati

• Entità e casi candidati formano insieme alle GUI i requisiti IT

• Entità e casi candidati sono successivamente sviluppati secondo modellazioni

UML canoniche

21


Assembly line: Entità Candidate

Fabbisogni

Produzione

Reparti Buy



e Prenotazioni


Fabbisogni

Lordi in PezziIdentificazione tipologia

codice


[codice in make]

[codice in buy]

Fabbisogni

Produzione

RepartiMake


FABB (Fabbisogni)



I (Impegni)


P (Prenotazioni)


Carica Previsioni Conferma QuoteOrdinate

Calcola FabbisogniLordi

Calcolo CapacitàNecessaria Make

Calcolo Capacità

Necessaria Buy

Imposta Previsioni

• La esecuzione di una singola

attività include una serie di

operazioni di lettura/scrittura su

entità (vedi tabella CRUD)

• Le entità indicate nelle AL sono

dette “candidate” in quanto solo

una successiva analisi affinerà la

loro progettazione

• Le entità candidate derivano dalle

ABE (specializzazione o

scomposizione)

• Le operazioni sulle entità sono

indicate da archi orientati

22


Assembly line: Casi d’uso candidati

Fabbisogni

ProduzioneReparti Buy



e Prenotazioni


FabbisogniLordi in Pezzi

Identificazione tipologia

codice


[codice in make]

[codice in buy]

FabbisogniProduzione

RepartiMake


FABB (Fabbisogni)



I (Impegni)


P (Prenotazioni)


Carica Previsioni Conferma QuoteOrdinate

Calcola FabbisogniLordi

Calcolo CapacitàNecessaria Make

Calcolo Capacità

Necessaria Buy

Imposta Previsioni

• I casi d’uso candidati indicano funzionalità del sistema svolte mediante la

interazioni di una attività con entità candidate

• La interazioni di una data attività possono essere incluse in uno o più casi

d’uso candidati

23


Assembly line: metodo

• Individuare le entità candidate (dalle ABE)

– Iniziare dalla prima attività

• Individuare le informazioni anagrafiche lette o scritte (p.e. cliente, prodotto ecc.)

• Riportare le informazioni come entitàcandidate

• Individuare le informazioni dinamiche lette o scritte (p.e. ordini cliente, conferme ordine)

• Riportare le informazioni come entitàcandidate

– Continuare con le altre attività

• Per ogni attività individuare i casi d’uso candidati (uno o più)

• Rivedere e rifinire le entità candidate e i casi d’uso candidati

24


Controllo della integrità : tavola CRUD

(Create, Read, Update, Delete)

• La tavola CRUD verifica la

completezza del ciclo vitale delle

entità candidate individuate nelle

assembly lines all’interno del

processo e del sistema

25




Legenda:

C = crea e inserisce

R = legge e non modifica

U = legge e modifica

D = cancella

…………..…………..…………..…………..…………..…………..…………..

…………..UR…………..CURCU #41

…………..…………..…………..…………..…………..…………..…………..

…………..…………..…………..…………..…………..…………..…………..

…………..…………..…………..…………..…………..…………..…………..

……………ORFORFORNITOR

I

……………MOVIMEN

TI

SCORTEANAGRAFE

MATERIAL

I

ENTITA CANDIDATE ATTIVIT

A - CU

26




• Verifica delle precedenze. Individua le eventuali anomalie di precedenza in sede di progetto. L’ordinamento delle funzioni nella tabella, infatti, rispecchia parzialmente l’ordine di precedenza delle attività:

– una C non può seguire una R o U (una registrazione deve esistere per essere letta o modificata);

– una D non può precedere una R o U (una registrazione non può essere letta o modificata se è già stata cancellata).

• Verifica di chiusura. Individua le informazioni che non completano il loro ciclo vitale di creazione, modifica, lettura e cancellazione nell’ambito delle funzioni di aggiornamento elencate nella tabella.

• Importazione. Le informazioni sono consultate (R) o modificate (U), ma non create (C) dal sistema. Queste informazioni devono essere generate da altri sistemi o da apposite funzioni di gestione archivi.

• Ridondanza. Le informazioni sono create (C) ma non consultate (R) né modificate (U). Le informazioni ridondanti, quando non utilizzate effettivamente da altri sistemi, vanno eliminate in quanto appesantiscono inutilmente le elaborazioni.

• Distruzione. Le informazioni sono cancellate (D) ma non create (C) né modificate (U). Questa casistica è segno di errori o di analisi incomplete.

27


Approcci complementari per derivare requisiti

• Le Assembly Lines sono un approccio semiformale per

identificare i requisiti IT corrispondenti a un dato schema di

processo modellato con Activity Diagram

• Per individuare i requisiti IT (= Casi d’uso, GUI, Classi di dati)

possono essere usati anche altri metodi p.e.

– Analisi della documentazione IT, organizzativa, moduli, rapporti, studio

delle funzionalità ERP utilizzate

– Prototipi software marcianti (metodi RAD e simili)

– Mock-up




Le assembly lines


Casi d’uso e collaudo

29



• I requisiti possono essere descritti

da asserzioni in linguaggio

naturale

• In ogni caso i requisiti vanno

numerati

– In base alla struttura del

documento dei requisiti

– In sequenza nella categoria del

requisito, con etichetta mnemonica

sulla categoria di appartenenza

– In base ad un identificatore

univoco generato da un database

dei requisiti (CASE)

• I requisiti possono essere

gerarchizzati

• La gerarchia riflette i livelli di

astrazione/dettaglio

• A ciascun livello dei requisiti

– Si può associare un caso d’uso

– Si può illustrare la relazione tra

requisiti e attori mediante

diagrammi dei casi d’uso.

30


Requisiti e casi d’uso : esempio

• 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.

31


Casi d’uso: diagramma

Cliente

VenditoreInserimento Ordine

Direttore

Convalida Ordine

• Lo stickman rappresenta lo

stereotipo <<actor>>.

• L’ovale rappresenta lo stereotipo

del caso d’uso.

• Ciascun nome deve riflettere una

funzionalità del sistema secondo

l’analisi dei requisiti.

• La freccia indica se l’attore innesca

il caso d’uso (afferente) o ne

subisce gli effetti (efferente)

32


Casi d’uso: diagramma – esempio

Commerciale

Direttore Produzione

Calcola Fabbisogni

Lordi

Calcolo Capacità

Necessaria Buy

Calcolo Capacità

Necessaria Make

Carica Previsioni

Conferma Quote

Ordinate

Imposta Previsioni

<<uses>>

<<includes>

>

<<includes>>

<<includes>>

33


Casi d’uso: diagramma (cont.)

Cliente


Direttore

Convalida Ordine

• Rappresentano i requisiti individuati con le AL

• Possono essere redatti a successivi livelli di astrazione (un caso d’uso può contenere casi d’uso più specifici).

• Rappresentano i requisiti del sistema ed enfatizzano che 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 (e i relativi diagrammi di specifica) sono sviluppati iterativamente e parallelamente al diagramma statico delle classi (entità candidate)

34


Casi d’Uso : proprietà

Cliente


Direttore

Convalida Ordine

• Un caso d’uso modella una funzionalità completa (flusso principale di esecuzione, flussi alternativi eventuali, condizioni di eccezione)

• Un caso d’uso è una funzionalità visibile esternamente dall’utente e come tale da esso percepita, interagendo con il sistema/software

• E’ eseguibile indipendentemente (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 (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 è produce sempre al termine dell’esecuzione un risultato significativo e percepibile come tale esternamente da un altro attore

35


Casi d’uso: Stereotipi e Associazioni

Cliente


Direttore

Convalida Ordine

• Associazione normale: indica 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 <<include>>: un caso d’uso di base comprende sistematicamente il comportamento descritto dal caso d’uso incluso. Il caso d’uso incluso non è eseguito solamente in quanto parte del caso d’uso di base.

• Estensione <<extend>>: estende il comportamento del caso d’uso base attivando un altro caso d’uso in alcuni casi (opzionali nel regolare funzionamento del caso d’uso base)

• Utilizzo <<use>>: un caso d’uso utilizza in parte o in tutto un altro caso d’uso per il suo completamento

36


Casi d’uso: Generalizzazione tra Attori

Cliente


Direttore

Convalida Ordine

• 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.

37


Casi d’uso : dettaglio con Activity Diagram

Inserimento

Ordine

Invio Acconto

Verifica Ordine

Controlla

Solvibilità

[ <= 5000 Euro ]

Ordina

Spedizione

Convalida

Ordine

[ > 5000 Euro ]

Annulla Ordine

[ Solvibile ]

[ Non Solvibile ]

DirettoreVenditoreCli ente• I diagrammi di attività possono essere

utilizzati per dettagliare 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.

38


Casi d’uso : dettaglio con Activity Diagram

Seleziona Cliente

Visualizza Previsioni Venditore per Cliente

Visualizza Previsioni Cliente per Cliente

Inserisci Conferma Ordine per Articolo per Cliente Conferma una Previsione come Impegno

Aggiorna Errore PrevisionaleAggiorna Errore Previsionale per Inserimento

Impegno Inserito

Finestra impegni vuota

[Ordine non previsto] [Conferma coincide con previsione]

[dati da verificare rispetto a previsioni]

Inserimento Interrotto

39


Caso d’uso: specifica (schema di Jacobson)

Caso d’uso

Attori Descrizione

Flusso eventi Flussi alternativi

Precondizioni Postcondizioni

Eccezioni Frequenza

Criticità

• Attori: attori afferenti o efferenti al caso

• Descrizione: frase che sintetizza la natura del caso

• Flusso Eventi: elenco numerato dei sottorequisiti che compongono il caso.

• Flussi Alternativi: modalità alternative di esecuzione del caso.

• Pre Condizioni: asserzioni che devono essere verificate perché il caso possa essere iniziato (si usa per stilare i piani di collaudo)

• Post Condizioni: asserzioni che devono essere verificate alla fine dell’esecuzione del caso d’uso (per i piani di collaudo)

• Eccezioni: possibili errori che devono essere rilevati nel sistema, di eventi che possono causare una esecuzione del caso d’uso non lineare/corretta (per i piani di collaudo)

• Frequenza stimata di utilizzo (per decidere le priorità nel piano di sviluppo)

• Criticità (per stimare il rischio legato al requisito)

40


Caso d’uso: specifica - esempio

1.1.1 [CU3]: Identificazione dei fabbisogni per codici a scorta :: Conferma Quote Ordinate

1.1.1.1 Attori

Commerciale

1.1.1.2 Breve Descrizione

Permette di visualizzare le previsioni di ordine per cliente e articolo , inserire un ordine e confrontare la previsione con l’ordine effettivo.

1.1.1.3 Flusso di Eventi

1.1.1.3.1 Flusso Base

[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 evidenzia se l’articolo è make or buy

[CU3.5] Il sistema evidenzia il prezzo standard dell’articolo e il tempo medio di realizzazione.

[CU3.6] Se presenti, il commerciale carica le previsioni inviate dal cliente

[CU3.7] Il commerciale inserisce i dati di conferma ordine pervenuti dal cliente.

[CU3.8]Se i dati della conferma ordine sono corrispondenti alla previsione, èsufficiente inserire i dati di conferma e trasformare la previsione in un impegno.

[CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono i dati e si crea un impegno.

1.1.1.3.2 Flussi Alternativi

[CU3.10] Il commerciale decide di non inserire l’impegno perché l’ordine è sensibilmente difforme alla previsione venditore.

[CU3.11] Il commerciale decide di non inserire l’impegno perché l’ordine è sensibilmente difforme alla previsione cliente.

[CU3.12] Il commerciale decide di non inserire l’ordine perchéil prezzo concordato è sensibilmente difforme al prezzo standard.

1.1.1.4 Pre Condizioni

Al commerciale perviene un ordine da trasformare in impegno.

1.1.1.5 Post Condizioni

E’ stato inserito un impegno a fronte dell’ordinativo, oppure non si è in alcun modo modificata la situazione precedente.

1.1.1.6 Eccezioni

Dati inseriti non validi

1.1.1.7 Frequenza Stimata di Utilizzo (bassa, media, alta)

ALTA

1.1.1.8 Criticità (bassa, media, alta)

ALTA

Backup - modellazione UML Activity Diagrams

42


Activity Diagram : Elementi grafici

*

Concorrenza dinamica

Attivita’

fork

[condition]

branch

[else]

[condition]

join

merge

start

end

43


Connettori: esecuzione condizionale

• BRANCH: l’attività ha una sola connessione in ingresso e più connessioni in

uscita dotate di condizioni; dopo la fine dell’azione le condizioni sono

valutate e solo l’azione “successore” la cui condizione è vera è eseguita (le

condizioni sono mutuamente esclusive);

• MERGE: l’attività ha più connessioni in ingresso e una connessione in uscita;

termina un blocco condizionale iniziato con un branch;

44


Connettori: esecuzione condizionale (1)

Verifica scelta

cliente sul tipo dispedizione

Spedizione

per corriereSpedizione

posta ordinaria

[spedizione rapida] [else]

Chiusura ordine

BRANCH

MERGE

45


Connettori: esecuzione condizionale (2)

Mostraremodulo di acquisto

Ottenere i dettagli

dell’acquisto

Memorizzare

l’ordine

[OK]

[incompleto]BRANCH

MERGE

46


Connettori: esecuzione parallela

• FORK:

– l’attività ha una sola connessione in ingresso e più connessioni in uscita;

– quando l’azione termina sono eseguite in parallelo tutte le azioni successive

• JOIN:

– l’attività ha più connessioni in ingresso e una connessione in uscita, e termina un blocco parallelo iniziato con un fork;

– l’attività uscente dal join può essere eseguita solo dopo che tutte le attività entranti nel join sono terminate (il join sincronizza le attività);

47


Connettori: esecuzione parallela (1)

Prelievo merce dal magazzino

Imballare la mercePreparare l’etichetta

per la spedizione

Etichettare la merce

per la spedizione

FORK

JOIN

48


Esercizio 1

(GUTT)

• E’ possibile prenotare telefonicamente o presentandosi in agenzia. In agenzia una persona si occupa solamente delle prenotazioni.

• Le prenotazioni sono registrate su un archivio

• L’agenzia stampa i tabulati delle prenotazioni ogni mattina per avere un quadro generale della situazione

• Le prenotazioni scadute vengono annullate

• E’ possibile chiamare l’agenzia per effettuare dei reclami, i reclami vengono archiviati.

49


Soluzione 1(GUTT)

Prenotazione

telefonica

Prenotazione

in agenz ia

Annulla

prenotazione

Ricezione

ReclamiR ichies ta telefo nica

Inizio

Fine

Stampa

tabulat i

Evade

Reclamo

Aggiorna Anagrafica

Prenotazioni

Aggiorna Anagrafica

Prenotazioni

prenotazioni s cadute

Controlla

Prenotazioni

fine giorno

fine giorno

50


Esercizio 2

(Check-in)

• Il cliente si presenta in aeroporto e consegna il suo biglietto al check in.

• L’impiegato verifica se la prenotazione è confermata e assegna un posto al cliente.

• I bagagli da imbarcare sono pesati e la loro segnalazione inserita nel sistema.

• La carta di imbarco è emessa e consegnata al cliente.

• Se la prenotazione risulta non confermata, il cliente è inserito in lista di attesa e riprende il suo biglietto.

51


Soluzione(Check-in)

Presentazione

biglietto aereo

Start

Verifica

prenotazione

As segnazione

posto

Pesa bagagli Archiviazione

dat i bagagl i

Emissione carta

di imbarco

Inserire cliente in

lista di attesaRest it uisce

biglietto aereo

Cons egna carta d i

imbarco

End

Prenotazione non valida

52


Esecizio 3

(Agenzia Viaggi via Internet)

• Consultazione catalogo viaggi: l’utente ha la possibilità di scegliere in base alla destinazione, al costo e alla durata di diverse vacanze (vacanze complete, solo alberghi oppure appartamenti). L’utente può effettuare la consultazione senza registrarsi.

• Prenotazione e acquisto viaggi: solo l’utente registrato può prenotare il viaggio. La prenotazione è confermata solo dopo il pagamento del viaggio con carta di credito o presso una agenzia associata. Sono previsti sconti in base all’età e alla fedeltà (se è in possesso della carta soci dell’agenzia)

53


Soluzione(Agenzia viaggi)

Start

Inserimento

destinazione

Scelta tariffa Scelta durata

Scelta tipo di

viaggio

Visualizza offerte

complete

viaggio com pleto

Visualizza

alberghi

solo alberghi

Visualizza

appartamenti

solo appartamento

Controlla se

utente registrato

Inserimento

età cliente

Richiesta

carta soci

Inserimento numero

carta socio

Calcola sconto

Calcola tariffa

Inserimeno

numero carta

Verifica carta

Addebito

spesa

P agam ento in

agenzia

Chiudi

sessione

utente non registratoutente regis trato

dotato di carta socio

pagam ento on-linepagam ento in agenzia

num ero errato

abort

54


Esercizio 4

(ITACA)

• Una recente ricerca condotta in ambito europeo ha registrato come l’incidenza degli acquisti di MRO (Material Requirement and Operation) sia intorno allo 8% dei costi delle PMI (piccole e medie imprese) nel settore elettromeccanico. Tale valore, decisamente alto, è imputabileallo scarso potere contrattuale delle PMI. Per questo motivo, nell’ambito del progetto ITACA finanziato dall’UE è stata sviluppata una piattaforma di aggregazione degli acquisti con lo scopo di favorire l’approvvigionamento delle PMI del settore elettromeccanico. La piattaforma di aggregazione opera in modalità ASP. Sua caratteristica principale è un modello degli acquisti MRO basato su un modello di consumo. Il modello memorizzato all’inizio del servizio, viene aggiornato ad ogni acquisto.

• Il processo di acquisto include le attività per sottomettere l’ acquisto all’aggregatore (BUY) e la ricezione della merce (RECEIVE):– [BUY]: la PMI a inoltra le richieste all’aggregatore e successivamente riceve un rapporto che riporta l’esito della richiesta. Il rapporto delle risposte positive

contiene l’ordine di acquisto che comprende la data di consegna della merce. In caso contrario il rapporto contiene un rifiuto all’acquisto perché non autorizzati (ad esempio la PMI non ha rinnovato il canone di servizio) o perché la richiesta non è in linea con il modello di acquisto.

– L’aggregatore effettua i controlli di rito sulla richiesta. Se la richiesta è accolta, aggiorna la storia dei consumi del distretto e controlla che sia disponibile un’aggregazione per l’ordine accettato. In caso negativo, l’ aggregazione viene creata.

– [RECEIVE]: A fronte della scadenza dei termini, è contattato il fornitore per richiedere la consegna della merce. Il fornitore si occupa della logistica interna: preparazione della fattura, imballo separato dei lotti e aggiornamento del magazzino a fronte del prelievo. Il processo di spedizione è terzializzato ad un corriere espresso selezionato sulla base della copertura geografica, dell’urgenza della consegna, della tipologia di mezzi ecc…

– Il corriere carica la merce direttamente dal fornitore. L’aggregatore contemporaneamente invia al cliente una conferma che si predisporrà per ricevere la merce.

55


Soluzione(ITACA)

Imba lla lotti

Contat ta

fornitore

Verifica ordine

Appli ca sconto

Aggiorna modello

di consumo

Disponi fattura

Aggiorna situazione

magazzino

Contatta

corriera

Spedisce

pacco

Spedisce notifica

a cliente

Fine

NewState

Soglia raggiunta

56


Soluzione(ITACA)

Formula richiesta

di acquisto

Inoltra

richiesta

Raccoglie

richiesta

verifica identitàcontrolla conf.

modello di acquisto

compila

rapporto

Aggi. modello

di consumo

Riceve e

controlla rapporto

A ggrega

acquisto

elseCrea nuova

aggregazione

nessuna aggregazione

End

Controlla aggregazioni

in corso

Predispone

magazzino

[ (ver. identità = OK) AND (contr. acqu. = OK) ]

[ non autorizzato ]

[el se]

ordine non conform e

[el se]

modellazione dei requisiti informativimb.unisalento.it/infoarchanddb/allegati/requirements.pdf ·...

Documents