Progettazione Concettuale e Modello di Progetto

Transcript

1 Progettazione Concettuale e Modello di Progetto

2 Metodologia di Progetto di SI PREFERIBILMENTE ITERATIVA (1) Analisi dei Requisiti (Modello di Business): analisi di scenario, individuando i processi, gli attori coinvolti e le informazioni richieste. (2) Progettazione Concettuale (Modello Progettuale): l analisi funzionale, individuando le funzioni che il sistema dovrà offrire, gli utenti abilitati, la struttura dei dati e le viste su di essi. (3) Progettazione Logica (Modello Realizzativo): gli aspetti implementativi, individuando la struttura architetturale del sistema, il livello di interfaccia e quello di accesso ai dati.

3 Riepilogo Modello di Business PACKAGE MODELLO BUSINESS Class diagram SchemaProcessi contenente i vari processi (rappresentati come package) e le loro dipendenze - rappresentazione della catena del valore all'interno dell'azienda: i processi sono raggruppati a partire dall'input (lato acquisti) passando per i processi interni (lato lavorazione) fino all'output (lato vendita) ed accanto quelli di supporto Package SchemaAttori contenente un use case diagram in cui sono identificati tutti i vari attori e le loro eventuali gerarchie di generalizzazione Package SchemaArchivi contenente un use case diagram in cui sono identificati i vari archivi, indicati come attori con stereotipo <<archive>>, utilizzando anche un apposita icona che ricordi un database (cilindro), e le loro eventuali gerarchie di generalizzazione Package per ogni processo P contenente un use case diagram UseCase P in cui il processo compare come use case con stereotipo <<process>> a cui sono collegate le attività come use cases tramite le frecce <<include>> o <<extends>> - alcune attività "estemporanee" (ad esempio riscontro ordini in un processo di acquisizione) potrebbero essere non collegate al processo in quanto vengono possono essere effettuate in qualsiasi momento senza pre o post condizioni Al processo P va associato un activity diagram WF P (dove WF sta per workflow) che descrive le relazioni di precedenza tra le attività del processo

4 Progettazione Concettuale Dopo l'analisi dei requisiti si passa alla progettazione concettuale. Tra le due fasi esiste un gap (frattura) in quanto da una visione ad alto livello abbastanza informale e rivolta all'utente, si passa a una specifica più formale e strutturata. Nella progettazione concettuale: vengono individuati gli attori attivi cioè che effettivamente interagiranno con il sistema; vengono individuati i processi automatizzati, cioè quelli le cui attività saranno realizzate con funzioni informatizzate le attività non informatizzate non vanno incluse; vengono descritti gli archivi secondo un modello di dati ad alto livello (versione UML del modello Entità-Relazioni) schema concettuale; vengono descritte anche le porzioni dello schema concettuale (viste) utilizzate dalle varie attività; viene prodotto il Modello di Progetto.

5 Modello di Progetto PACKAGE MODELLO PROGETTO Package SchemaFunzioni contenente un class diagram SchemaFunzioni che descrive i vari gruppi di funzioni (rappresentati come package) e le loro dipendenze - non necessariamente un gruppo di funzione corrisponde a un processo ma in generale è preferibile che ciò avvenga anche se non tutte le attività del processo verranno poi automatizzate Package SchemaAttori contenente un use case diagram in cui sono identificati tutti i vari attori attivi e le loro eventuali gerarchie di generalizzazione Package SchemaDati contenente un class diagram che descrive dettagliatamente e formalmente tutti i dati (classi ed attributi) utilizzati dalle funzioni Package SchemaViste contenente un use case diagram in cui sono identificati tutti le viste utilizzate dalle funzioni indicati come attori con stereotipo <<view>> - per ogni vista più significativa va riportato package apposito con all'interno un diagramma delle classi che descrive classi e associazioni coinvolte nella vista

6 Il Package SchemaAttori rispetto al modello di business spariscono molte figure e compaiono generalizzazioni rispetto alle funzionalità del sistema disponibili

7 Il Package SchemaDati

8 Il Package SchemaFunzioni /1

9 Il Package Schema Funzioni /2 Come si descrive una funzione la struttura dello use case diagram è analoga a quella del processo nel modello di business Funzione Dipendenza

10 Il Package di un Gruppo di Funzioni/1 All'interno del package SchemaFunzioni, un package per ogni gruppo di funzioni (processo) contenente: Ogni processo comprende un use case diagram in cui sono inseriti varie funzioni tra di loro eventualmente collegate tramite le frecce <<include>> o <<extends>> o di generalizzazione Ogni funzione corrisponde a una attività del modello di business che è svolta da un unico attore che interagisce con il sistema in un periodo di tempo limitato - alla funzione va associata come attore "passivo" (stereotipo <<view>>) la vista dei dati su cui essa opera Nella descrizione di una funzione dovranno essere descritti tutti i passi di essa in uno stile procedurale, con numerazione dei passi, e utilizzo di uno scenario (flusso di esecuzione) principale e di eventuali scenari alternativi inclusi scenari di errori Possono essere inserite pre-condizioni (cioè quali condizioni debbono essere soddisfatte prima di attivare la funzione) e post-condizioni (quali condizioni saranno soddisfatte al completamento della funzione)

11 Il Package di un Gruppo di Funzioni/2 Come si descrive una funzione la struttura dello use case diagram è analoga a quella del processo nel modello di business

12 Il Package SchemaViste /1

13 Il Package SchemaViste /2

14 Il Package SchemaViste /3