Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Automazione della gestione degli ordini d acquisto di una società di autonoleggio"

Transcript

1 Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1

2 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO DI RIFERIMENTO pag.4 CAPITOLO 1 IL BUSINESS MODELLING L ATTIVITA DI BUSINESS MODELLING...pag.5 I MODELLI UTILIZZATI NEL BUSINESS MODELLING...pag.5 IL COSTRUTTO CASO D USO E GLI STEREOTIPI UTILIZZATI..pag.6 COME SI SVOLGE LA DISCIPLINA DEL BUSINESS MODELLING.pag.9 Unit Organization Diagram. pag.9 Business System Diagram...pag.10 Business Use Case Diagrams..... pag.11 Business Use Case Realization Diagrams.pag.17 Il Diagramma delle Classi pag.23 I diagrammi di stato.. pag.25 I diagrammi delle attività. pag.27 CAPITOLO 2 ANALISI E DEFINIZIONE DEI REQUISITI DAL BUSINESS MODELLING AL SYSTEM MODELLING..pag.31 APPROCCIO METODOLOGICO UTILIZZATO..pag.32 DEFINIZIONE DEGLI STEREOTIPI.pag.35 IL DOCUMENTO DEI REQUISITI pag.36 TRACE DIAGRAM:USE CASE E USE CASE REALIZATION..pag.38 TRACE DIAGRAM: ACTOR.. pag.43 2

3 INTRODUZIONE L obiettivo della tesina è l automazione della gestione degli ordini di acquisto di una società di autonoleggio. In particolare si vuole controllare i flussi delle spese di marketing, controllare il budget, controllare la gestione dei pagamenti relativi agli ordini d acquisto, verificare i codici di budget, raggruppare le spese di investimento per singolo progetto pubblicitario. Attualmente viene fatta una gestione manuale attraverso una cartella MS EXCEL contenente più file. Ad ogni file corrisponde un area di investimento (Es. Luminose, radio, televisione, altro); ogni file è suddiviso in più fogli ognuno corrispondente ad una sottocategoria (ad esempio per l area Luminose si hanno le sottocategorie Luminose Aeroportuali, Luminose Ferroviarie, Luminose su strada, ecc). Nella tesina è stato proposto il piano metodologico di riferimento dove sono state analizzate, in particolare, le discipline del Business Modelling e dell analisi e definizione dei requisiti con la conseguente stesura di tutti gli elaborati di riferimento elencati nel piano metodologico. 3

4 IL PIANO METODOLOGICO DI RIFERIMENTO Per lo sviluppo del progetto si fa riferimento al seguente piano metodologico: DISCIPLINA MODELLO ELABORATO BUSINESS MODELLING Linguaggio naturale UML Organization Unit Diagram Business System Diagram Business Use Case Diagrams Business Use Case Realization Diagrams State diagrams Class diagram Activity diagrams ANALISI E DEFINIZIONE DEI REQUISITI Linguaggio naturale UML Trace diagram: use case Trace diagram: use case realization Trace diagram: actor Documento dei requisiti Avvalersi di un piano metodologico di riferimento equivale ad avere chiare: Le discipline ovvero le attività da svolgere; I modelli da utilizzare per ogni singola attività; Gli elaborati da produrre 4

5 CAPITOLO 1 BUSINESS MODELLING 1.1 L ATTIVITA DI BUSINESS MODELLING Nel caso di automazione di un sistema o di parte del sistema il punto da cui partire è la modellazione di business. L obiettivo del Business Modelling è la realizzazione di modelli del dominio del problema che descrivono logicamente la proposta di soluzione del sistema (il cosa deve fare) che sarà successivamente dettagliata e realizzata durante la progettazione e realizzazione. In questa attività verranno prodotti degli elaborati (diagrammi statici e dinamici, rappresentati con la notazione UML) che costituiscono una rappresentazione del problema che deve essere risolto. La finalità della modellazione sono: La visualizzazione del sistema così com è; Specifica della struttura e del comportamento del sistema; Definizione delle linee guida per la costruzione di un sistema; Documentazione delle decisioni prese. 1.2 I MODELLI UTILIZZATI NEL BUSINESS MODELLING Per quanto riguarda la disciplina del Business Modelling i modelli utilizzati sono il linguaggio naturale e UML. L UML è un linguaggio per descrivere, specificare e documentare i prodotti del processo di sviluppo del software. UML consente di rappresentare e di mantenere diverse viste di uno stesso sistema descrivendo gli oggetti che lo compongono da diversi punti di 5

6 osservazione, strutturale e comportamentale e a diversi livelli di astrazione. UML è un linguaggio di progettazione e non un linguaggio di programmazione come JAVA, Visual Basic, C++.. UML, nella versione 2.0, comprende 13 diagrammi ufficiali che vengono classificati in funzione dell aspetto del sistema che si propongono di descrivere: Diagrammi strutturali, che consentono di modellare la struttura del sistema; Diagrammi comportamentali, che descrivono il comportamento assunto dal sistema. Ogni diagramma va a rappresentare una vista (parziale) del sistema. Oltre alla vista strutturale ( diagramma delle classi ) e comportamentale ( diagramma use case, diagramma delle attività ), è possibile descrivere anche come il sistema evolve nel tempo, offrendo una vista dinamica del sistema (ad es. con il diagramma di stato macchina ). 1.3 IL COSTRUTTO CASO D USO E GLI STEREOTIPI UTILIZZATI In primo luogo occorre chiarire il concetto di caso d uso. I casi d uso rappresentano la modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori). Descrivono l interazione tra attori e sistema, non la logica interna della funzione e vengono espressi in forma testuale, in modo tale che siano comprensibili anche ai non addetti ai lavori. Costrutto CASO D USO; 6

7 Il caso d uso può essere utilizzato a livello di business e a livello di sistema. In ciascuno di questi due casi sarà assegnato uno stereotipo diverso in modo da poter distinguere quando il costrutto descrive l interazione con il sistema o l interazione con il software. Di seguito vengo riportati gli stereotipi utilizzati nella modellazione di business: - Stereotipo Business Use Case - Stereotipo Business Use Case Realization - Stereotipo Business Worker I Business Worker rappresentano un ruolo all interno dell organizzazione che partecipa in un processo di business e che può manipolare degli oggetti di business e interagire con altri business worker. 7

8 - Stereotipo Business Actor Il Business Actor rappresenta un ruolo esterno all organizzazione che interagisce con un processo di business. Stereotipo Organization Unit Si assegna lo stereotipo di Organization Unit a rappresentare l azienda (Enterprise) nella sua totalità. Stereotipo Business System Lo stereotipo Business System si assegna per rappresentare ciascuna delle parti (Department) che compongono l azienda. 8

9 1.4 COME SI SVOLGE LA DISCIPLINA DEL BUSINESS MODELLING È possibile riassumere l attività di modellazione in una serie di passaggi: 1) Individuazione delle Organization Unit; Unit Organization Diagram Nel nostro caso il sistema azienda è costituito dall unità organizzativa società di autonoleggio. SOCIETA DI AUTONOLEGGIO 2) Per l Organization Unit si trovano i Business System; Business System diagram L approccio più attuale per affrontare lo studio delle organizzazioni aziendali è quello di applicare a queste i concetti della teoria dei sistemi, secondo la quale, un sistema complesso, può essere suddiviso in sottosistemi che sono a loro volta dei sistemi più semplici. Nel nostro caso, l Organization Unit società di autonoleggio è stata scomposta nei 3 Business System che sono: 9

10 UFFICIO ACQUISTI; MARKETING; AMMINISTRAZIONE. I Business System in cui è stata suddivisa l azienda, nella successiva fase di modellazione, saranno sottoposti ad una specifica più approfondita: 2 livelli, quello dei Business Use Case (BUC) e quello dei Business Use Case Realization (BUCR). 3) Per ogni Business System individuo le classi di attori in gioco; Nel Business System Ufficio Acquisti sono coinvolti le seguenti classi di attori: Responsabile Ufficio Acquisti Operatore acquisti Fornitore 10

11 Nel Business System Marketing abbiamo come attore il Responsabile Marketing. Nel Business System Amministrazione abbiamo la classe d attore operatore amministrativo. Di seguito si riporta il diagramma degli attori relativo a ciascun Business System: Al fornitore è stato assegnato lo stereotipo Business Actor in quanto rappresenta un ruolo esterno all organizzazione che interagisce con l Ufficio Acquisti; gli altri attori coinvolti sono contrassegnati con lo stereotipo Business Worker in quanto rappresentano un ruolo all interno dell organizzazione e possono manipolare oggetti di business. 4) Per ogni classe di attori si individuano i Business Use Cases (BUCs) Business Use Case Diagrams Un caso d uso equivale alla descrizione di un insieme di azioni in sequenza, incluse le possibili varianti, svolte al fine di generare un risultato osservabile dal punto di vista dell utente. Quest ultimo assume il ruolo di 11

12 attore che interagisce con il sistema proprio tramite i casi d uso, con lo scopo di perseguire un obiettivo ben specifico. Il sistema azienda può essere descritto da un insieme di Business Use Cases capaci di fornire servizi agli attori interni ed esterni. Il caso d uso di Business descrive una sequenza di attività, effettuate nel Business, che producono un risultato osservabile e di valore per un attore. Di seguito si riportano i Business Use Case diagrams relativi ai 3 Business System: Per quanto riguarda l attore operatore acquisti sono stati individuati 4 business use case rilevanti per l organizzazione. Essi sono: 12

13 1) gestione archivio fornitori: l operatore acquisti può aggiungere un fornitore all archivio (caricando tutti i suoi dati: numero di telefono, ragione sociale, partita IVA, indirizzo), eliminarlo dall archivio o modificare i suoi dati. 2) gestione archivio preventivi: l operatore acquisti registra i preventivi effettuati dai vari fornitori. La registrazione di un nuovo preventivo pervenuto avviene attraverso la scelta del fornitore, la registrazione del codice identificativo del preventivo (proprio del fornitore) e la descrizione del preventivo. Allo stesso tempo può anche eliminare i preventivi dall archivio. 3) gestione archivio ordini d acquisto: l operatore acquisti crea l ordine ed inserisce l ordine creato nell archivio. Per inserire l ordine d acquisto occorre indicare: il progetto di riferimento, il numero di ordine, l area e la sottocategoria di riferimento, il fornitore scelto, le spese di investimento cui fa riferimento e l importo della specifica spesa. Deve essere possibile richiamare tutti gli ordini di acquisto per numero d ordine o per sottocategoria. Selezionato un ordine devono essere visualizzati i dettagli dell ordine e permettere di modificare, eliminare, aggiungerne eventuali altri relative a nuove spese di investimento. L emissione dell ordine avviene dopo la validazione da parte del responsabile ufficio acquisti. 4) gestione archivio fatture passive: occorre registrare le fatture passive indicando il fornitore, la data di emissione, il numero della fattura, l importo complessivo, il numero di preventivo di riferimento e altri dettagli. Le fatture passive registrate devono essere richiamate per fornitore, n preventivo e sottocategoria per vedere le fatture da pagare, pagate o in pagamento, in un intervallo di tempo. 13

14 Al fornitore, attore esterno all organizzazione, sono legati due casi d uso: emissione preventivo ed emissione fattura passiva. Il responsabile ufficio acquisti è legato a 4 casi d uso rilevanti per il sistema azienda: 1) la validazione e messa in pagamento delle fatture passive: dopo la registrazione della fattura passiva da parte dell operatore acquisti, il responsabile ufficio acquisti provvede alla validazione e messa in pagamento delle fatture passive. Il pagamento spetterà, poi, all operatore amministrativo. 14

15 2) la validazione dei preventivi 3) la validazione dell ordine: il responsabile acquisti valida l ordine dopo di che l operatore acquisti emette l ordine. 4) l operazione di riconciliazione: la riconciliazione è l operazione che permette di quadrare il budget per una sottocategoria o area rispetto alle spese effettivamente sostenute, ovvero di cui si è emesso l ordine d acquisto. Essa permette, quindi, di sapere in ogni momento il budget residuo per area e/o per sottocategoria. Al responsabile marketing sono associati 4 casi d uso rilevanti per l organizzazione: 15

16 1) definizione del piano d investimento: annualmente il responsabile marketing aveva il compito di creare nuova/e area/e di investimento; successivamente creava nuova/e sottocategoria/e associata/e a quell area/e ed infine andava a definire la spesa di investimento. Per ogni area creata vi si assegna un codice (una lettera dell alfabeto che indica l area di investimento). Per ogni sottocategoria creata vi si assegna un codice numerico di tre cifre. 2) Definizione budget annuale: il responsabile marketing assegnava un budget all area e un budget per ogni sottocategoria dell area. 3) Avanzamento: l avanzamento deve avvenire a richiesta e calcola il totale di tutte le spese di investimento degli ordini per ciascuna sottocategoria fino ad una data indicata. Effettuata l elaborazione, occorre visualizzare il budget per area e il totale speso per area. 4) Gestione archivio aree di investimento: deve essere possibile l inserimento di una nuova area e sottocategoria con i rispettivi codici per cui si intende visualizzare il budget; per ogni area si deve visualizzare il budget totale e il budget di tutte le sottocategorie dell area. Deve essere possibile visualizzare budget, budget speso e budget residuo per area e anche per singola sottocategoria. Calcolato il totale di tutte le spese di investimento degli ordini di ciascuna sottocategoria ad una certa data (avanzamento) occorre visualizzare il budget per area e il totale speso per area. 16

17 La classe operatore amministrativo è responsabile del pagamento delle fatture. 5) Per ogni Business Use Case, si vanno ad individuare da 1 n Business Use Case Realization; Business Use Case Realization Diagrams Il BUCR Diagram rappresenta le modalità secondo le quali lo USE Case viene realizzato rispetto alla classe di attori attraverso un processo di <<realize>>. Per ogni BUC sono stati individuati i BUCRs. Di seguito sono riportati i BUCR Diagram per ogni Use Case del Business System: UFFICIO ACQUISTI 17

18 Il Business Use Case Gestione archivio preventivi viene realizzato dagli Business Use Case Realization Gestione preventivi e validazione dei preventivi rispettivamente rispetto alle classi di attori operatore acquisti e responsabile ufficio acquisti, attraverso un processo di <<realize>>. 18

19 Il Business Use Case Gestione archivio ordini d acquisto viene realizzato dagli Business Use Case Realization Gestione ordini d acquisto e validazione degli ordini d acquisto rispettivamente rispetto alle classi di attori operatore acquisti e responsabile ufficio acquisti, attraverso un processo di <<realize>>. Il Business Use Case Gestione archivio fatture passive viene realizzato dagli Business Use Case Realization Gestione fatture passive, validazione e messa in pagamento delle fatture passive, pagamento delle fatture passive rispettivamente rispetto alle classi di attori operatore acquisti, responsabile ufficio acquisti e operatore amministrativo, attraverso un processo di <<realize>>. 19

20 20

21 MARKETING 21

22 22

23 AMMINISTRAZIONE IL DIAGRAMMA DELLE CLASSI Il diagramma delle classi è uno strumento fondamentale per le metodologie Object Oriented ed è utilizzato in diversi momenti del ciclo di vita di un sistema informativo per modellarne la struttura statica a diversi livelli di astrazione: per descrivere modelli concettuali nelle attività di analisi, per definire delle specifiche nel corso del progetto, per definire particolari tecniche di implementazione. I diagrammi delle classi mostrano le classi che modellano un dominio di un problema e le loro relazioni, in particolare descrive i tipi di oggetti che fanno parte di una classe. Descrive, infine, le relazioni statiche che intercorrono tra le classi (di dipendenza, associazione, generalizzazione e realizzazione), le proprietà ovvero gli attributi e le operazioni di una classe. Nel nostro caso sono state individuate 15 classi. La classe personale è legata a quella di responsabile ufficio acquisti, responsabile marketing, operatore acquisti e operatore amministrativo tramite una relazione di specializzazione. 23

24 24

25 I DIAGRAMMI DI STATO Descrivono il comportamento assunto da un singolo oggetto durante il suo ciclo di vita, cioè mostrano la macchina a stati che modella la logica di controllo di un oggetto. Un oggetto può assumere diversi stati nel contesto dei casi d uso ai quali partecipa e i suddetti diagrammi servono proprio a chiarire la logica con la quale avviene il passaggio da uno stato all altro. Gli elementi principali di questo diagramma sono tutti i possibili stati e le transizioni che indicano i possibili passaggi di stato. I diagrammi di stato offrono una vista dinamica del sistema. Di seguito sono riportati i diagrammi di stato relativi alle istanze: Preventivo 25

26 I possibili stati dell oggetto preventivo sono: non caricato, caricato e validato. Le transizioni, che determinano il passaggio da uno stato all altro, sono: preventivo creato, caricamento e validazione. Fattura passiva: I possibili stati degli oggetti della classe fattura passiva sono: non registrata, registrata, validata, in attesa di pagamento e poi pagata parzialmente o pagata a seconda che il pagamento sia parziale o totale. Le transizioni che determinano il passaggio da uno stato all altro sono: fattura creata, registrazione, validazione, messa in pagamento, pagamento parziale, pagamento totale. 26

27 Ordine d acquisto: I possibili stati dell oggetto ordine d acquisto sono: non registrato, registrato, validato, emesso. Le transizioni che determinano il passaggio da uno stato all altro sono: ordine creato, registrazione, validazione, emissione. I DIAGRAMMI DELLE ATTIVITA I diagrammi delle attività sono in grado di modellare gli aspetti dinamici di un sistema in quanto rappresentano l insieme di azioni da svolgere per ottenere un certo risultato. Tali diagrammi mostrano i flussi tra le attività, cioè fra azioni non atomiche e permettono la rappresentazione di processi paralleli e della relativa sincronizzazione. Di seguito sono riportati i diagrammi delle attività relativi: 27

28 Al sottoprocesso gestione ordini d acquisto: L operatore acquisti crea l ordine di acquisto. Si procede, poi, con la registrazione dell ordine da parte dell operatore acquisti. Se l ordine caricato viene validato dal responsabile ufficio acquisti si procede con l emissione dell ordine d acquisto da parte dell operatore acquisti. Il processo termina con la ricezione dell ordine da parte del fornitore. In caso di ordine non validato si procede con la creazione di un nuovo ordine d acquisto da parte dell operatore acquisti. 28

29 Al sottoprocesso gestione fattura passiva; Il fornitore emette ed invia la fattura passiva. L operatore la riceve e provvede alla sua registrazione. Dopo di che il responsabile ufficio acquisti provvede alla validazione e messa in pagamento della fattura. 29

30 Al Sottoprocesso gestione preventivo: L operatore acquisti emette la richiesta di preventivo; il fornitore la riceve e successivamente emette il preventivo e lo invia. L operatore acquisti lo riceve e provvede poi al caricamento. Il responsabile ufficio acquisti fa la validazione dei preventivi. In caso di non validazione il preventivo viene respinto. 30

31 CAPITOLO 2 ANALISI E DEFINIZIONE DEI REQUISITI 2.1 DAL BUSINESS MODELLING AL SYSTEM MODELLING La disciplina di analisi e definizione dei requisiti ha l obiettivo di documentare compiutamente ciò che il sistema deve fare, in modo da garantire facilità di comunicazione tra cliente e sviluppatori. Per realizzare il trasferimento dei requisiti di business a livello dei requisiti software si procede ad una duplice operazione di <<trace>> che interessa sia l aspetto comportamentale che quello strutturale, permettendo dunque che entrambi gli aspetti progrediscano parallelamente. La logica da seguire nell applicazione dell operazione di tracciatura si riassume nella scelta di quali siano le parti del business che necessitano di essere automatizzate: la prima operazione di <<trace>> interesserà esclusivamente i BUCs che devono essere automatizzati; la seconda operazione di <<trace>> in SUCRs sarà effettuata limitatamente ai BUCRs che, in qualche maniera, prendono parte all automazione del processo. Allo stesso modo vengono tracciati tutti quegli attori di business che comporteranno un corrispettivo a livello di sistema: si ottiene così un primo modello del sistema. La disciplina di analisi e definizione dei requisiti si avvale del linguaggio naturale e di UML. 31

32 2.2 L APPROCCIO METODOLOGICO UTILIZZATO Per quanto riguarda il passaggio dal Business Modeling al System Modeling esistono due differenti approcci metodologici: 1. La metodologia tradizionale, basata sul RUP, propone una soluzione di carattere iterativo e incrementale ricorrendo a un framework di tipo model driven che pone i casi d uso al centro dell attività di modellazione. La metodologia a cui ci si riferisce è costituita da 4 layers distinti ed è basata su un approccio top down di tipo iterativo e incrementale che procede per raffinamenti successivi: i primi due layers di analisi dei casi d uso riguardano più specificamente la modellazione di business ed hanno l obiettivo di fornire una rappresentazione completa e approfondita della realtà aziendale; i due layers sottostanti invece, riguardano la modellazione 32

33 di sistema, che equivale alla rappresentazione del software destinato ad automatizzare il sistema aziendale o un sottosistema. Con l applicazione di tale metodologia si ha la possiblità di descrivere entrambi gli aspetti, quello di business e quello di sistema, con ricchezza sempre maggiore di particolari e, soprattutto, viene assicurato il passaggio da un modello all altro senza perdita di informazioni. Il processo è, infatti, guidato dai casi d'uso, use case driven, che ritroviamo sia a livello di business che di sistema, seppur rappresentati con stereotipi differenti a sottolineare la diversa valenza. Con la metodologia RUP il passaggio dal modello CIM (Computetional Indipendent Model), formato dai primi due layers, al modello PIM (Platform Indipendent Model) avviene attraverso un operazione di <<trace>>. La logica da seguire è semplice: una volta individuati tutti i BUCRs (per ognuno dei BUCs) si stabilisce quali di questi andranno automatizzati. In questo modo si individuano i SUCs e, con il successivo <<realize>>, i SUCRs che completano il modello PIM. In altre parole, i passi da seguire sono i seguenti: a) Individuo i business system b) Individuo i BUCs c) Vado a realizzare ciascun BUC attraverso 1 n BUCR d) Faccio l operazione di trace per ogni BUCR definisco un SUC e per ogni SUC individuo le sue realizzazioni (SUCRs). 2. C è poi una metodologia innovativa che introduce alcune novità significative: 33

34 Anche questo approccio prevede 4 layers distinti, due per la modellazione a livello di business e due per la modellazione a livello di sistema, entrambi collegati tra loro da un operazione di <<realize>>. Quello che cambia è la relazione che intercorre tra modello di business e modello di sistema: viene introdotta, infatti, una doppia operazione di <<trace>> che dai livelli di business conduce ai due livelli di modellazione del sistema. In questo modo si possono riprodurre tutti i BUCs e i relativi BUCRs nella prospettiva di sistema, trasformandoli rispettivamente nei SUCs e nei SUCRs. L obiettivo dell operazione di <<trace>> resta quello di trasferire alla modellazione di sistema solo ciò che è destinato all automazione. Procedendo secondo questo approccio metodologico, si esegue una doppia operazione di <<trace>> con la quale i BUCs vengono tracciati nella prospettiva di sistema divenendo SUCs (terzo layer) e, parallelamente, i BUCRs vengono tracciati divenendo SUCRs (quarto layer). 34

35 Con questa metodologia prendo i BUC e uno a uno li trasformo in SUC; poi prendo i BUCR e uno a uno li trasformo in SUCRs. Con questo approccio, si va ad eliminare qualsiasi forma di aleatorietà, che, invece, poteva sorgere utilizzando la metodologia RUP. Per il nostro progetto faremo riferimento alla seconda proposta metodologica. OSS. Nell operazione di trace devo dire quali sono gli elementi del Business Modeling interessati all automazione prendo solo i BUC interessati all automazione e li traccio. I BUC non interessati dall automazione non vanno tracciati. Grazie al doppio trace definisco un modello PIM perfettamente aderente al CIM. 2.3 DEFINIZIONE DEGLI STEREOTIPI Stereotipo System Use Case; Stereotipo System Use Case Realization; Stereotipo System Actor; 35

36 2.4 IL DOCUMENTO DEI REQUISITI L input per la realizzazione del documento dei requisiti sono tutti gli elaborati prodotti nella attività di Business Modeling. Tale documento conterrà l insieme dei requisiti finalizzati ad individuare le parti del sistema da automatizzare. La raccolta dei requisiti è stata fatta tramite colloqui formali e documenti scritti. Di seguito sono riportati i requisiti principali prima a livello di sistema globale (a livello di unit Organization) e, successivamente, a livello di singolo sottosistema (Business System). Requisiti a livello di unit Organization Il sistema deve automatizzare la gestione degli ordini di acquisto della società di autonoleggio; bisogna controllare i flussi delle spese di 36

37 marketing; bisogna controllare il budget; verificare i codici di budget; controllare la gestione dei pagamenti relativi agli ordini di acquisto; raggruppare le spese di investimento per singolo progetto pubblicitario. Requisiti a livello dei singoli Business System: a) Ufficio acquisti: 1) L operatore acquisti crea l ordine e lo inserisce nell archivio indicando il progetto di riferimento, il numero di ordine, la sottocategoria di riferimento, l importo complessivo previsto, il fornitore scelto. 2) L operatore acquisti deve poter richiamare tutti gli ordini d acquisto per numero d ordine o per sottocategoria. 3) L operatore acquisti deve poter richiamare una fattura passiva già registrata per fornitore, n preventivo e sottocategoria. L operatore acquisti registra tutte le fatture emesse a fronte di un ordine ognuna nella pagina della sottocategoria di riferimento, indicando il fornitore, la data di emissione, il numero, l importo complessivo, il n di preventivo di riferimento e altri dettagli eventualmente. 4) L operatore acquisti carica i preventivi nell archivio indicando la descrizione del progetto di riferimento, i dettagli del fornitore e il codice identificativo del preventivo (proprio del fornitore). 5) Il responsabile acquisti chiede la riconciliazione: l operazione che permette di quadrare il budget per una sottocategoria o area rispetto alle spese effettivamente sostenute, ovvero di cui si è emesso l ordine di acquisto. Essa permette, quindi, di sapere, in ogni momento il budget residuo per area e/o per sottocategoria. b) Marketing: 1) Il responsabile marketing definisce annualmente il piano di investimento, ovvero crea nuove aree di investimento, crea nuove sottocategorie e definisce le spese di investimento. 37

38 2)Il responsabile marketing deve definire un budget annuale per ciascuna area e per ciascuna sottocategoria dell area. 3)Il responsabile marketing effettua l avanzamento, cioè calcola il totale di tutte le spese di investimento degli ordini per ciascuna sottocategoria fino ad una data indicata. 4)Deve essere possibile visualizzare il budget totale per area e per sottocategoria, calcolare e visualizzare il budget residuo per area e per sottocategoria e il budget speso. c) Amministrazione: 1) L operatore amministrativo paga le fatture passive, totalmente o parzialmente. 2.5 TRACE DIAGRAM: USE CASE E USE CASE REALIZATION Il passaggio dal Business Modelling al System Modelling è stato svolto con una doppia operazione di trace coerentemente con quanto introdotto dalla proposta metodologica utilizzata. Con questo nuovo approccio è possibile raggruppare assieme in un unico diagramma dei casi d uso le varie attività di <<realize>> e <<trace>> in modo da avere così una visione globale di come le modalità operative aziendali sono portate avanti e come esse devono essere automatizzate. L operazione di trace degli BUCs in SUCs e degli BUCRs in SUCRs viene realizzato nello stesso istante. Nel processo di trace vanno considerati solo i BUCs ed i relativi BUCRs interessati all automazione. Nel nostro caso i BUCs da automatizzare e che, quindi, verranno tracciati per diventare SUCs, sono Gestione archivio ordini d acquisto, gestione 38

39 archivio fatture passive, riconciliazione, gestione archivio aree di investimento, avanzamento. La prima operazione di <<trace>> interessa il BUC Gestione archivio ordini d acquisto ; la seconda operazione di <<trace>> interessa il BUCR Gestione ordini d acquisto che prende parte all automazione del processo. 39

40 La prima operazione di <<trace>> interessa il BUC Gestione archivio fatture passive ; la seconda operazione di <<trace>> interessa il BUCR Gestione fatture passive che prende parte all automazione del processo. 40

41 La prima operazione di <<trace>> interessa il BUC Riconciliazione ; la seconda operazione di <<trace>> interessa il BUCR Riconciliazione che prende parte all automazione del processo. La prima operazione di <<trace>> interessa il BUC Gestione archivio aree di investimento ; la seconda operazione di <<trace>> interessa il BUCR Gestione aree di investimento che prende parte all automazione del processo. 41

42 La prima operazione di <<trace>> interessa il BUC Avanzamento ; la seconda operazione di <<trace>> interessa il BUCR Avanzamento che prende parte all automazione del processo. 42

43 2.6 TRACE DIAGRAM: ACTOR Vengono, infine, tracciati tutti quegli attori di business che comporteranno un corrispettivo a livello di sistema 43

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali

Università degli studi dell Aquila. Sistemi informativi aziendali Università degli studi dell Aquila Sistemi informativi aziendali 6 C.F.U. 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U.

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U. Università degli studi dell Aquila Sistemi informativi aziendali 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti (2 ore)

Dettagli

Gestione del workflow

Gestione del workflow Gestione del workflow Stefania Marrara Corso di Tecnologie dei Sistemi Informativi 2004/2005 Progettazione di un Sistema Informativo Analisi dei processi Per progettare un sistema informativo è necessario

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML)

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) a cura di Giacomo PISCITELLI Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Questi appunti sono ricavati da una

Dettagli

Ingegneria del Software I. UML - Use Case Diagram

Ingegneria del Software I. UML - Use Case Diagram Requisiti e casi d uso Unified Modeling Language Use Case Diagram 1 Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisiti Definizione del Business Model Solitamente informale

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione Luca Cabibbo Architetture Software Dispensa T 1 ottobre 2008 1 -Fonti [Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione [Larman] Applicare UML e i pattern, Capitolo

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

Dettagli

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it Progetto Struttura del documento di specifica dei requisiti, Casi d uso manuel.comparetti@iet.unipi.it 1 Documenti da produrre Il progetto deve comprendere i seguenti documenti: Documento di specifica

Dettagli

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Un negozio di musica vende anche libri e riviste musicali. Si intende automatizzare l intero processo, dall approvvigionamento alla vendita. Si analizzino i requisiti e se ne rappresentino

Dettagli

UML - Unified Modeling Language

UML - Unified Modeling Language UML E CASI D USO UML - Unified Modeling Language Linguaggio stardardizzato per identificare e modellizzare le specifiche di un S.I. Coerente con il paradigma della programmazione ad oggetti Definito a

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Prof. Andrea Borghesan & Dr.ssa Francesca Colgato venus.unive.it/borg borg@unive.it Ricevimento: mercoledì dalle 10.00 alle 11.00 Modalità

Dettagli

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali Introduzione Sistemi Informativi Linguaggi per la modellazione dei processi aziendali Paolo Maggi Per progettare un sistema informativo è necessario identificare tutti i suoi elementi

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi Metodologie e modelli per la progettazione di basi di dati Introduzione alla progettazione Il problema: progettare una base di base di dati a partire dai suoi requisiti Progettare: definire la struttura,

Dettagli

Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011. DATALOG Soluzioni Integrate a 32 Bit

Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011. DATALOG Soluzioni Integrate a 32 Bit KING Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011 DATALOG Soluzioni Integrate a 32 Bit - 2 - Manuale di Aggiornamento Sommario 1 Comunicazione Operazioni rilevanti IVA per

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Model Driven Software Development con Eclipse, StatechartUMC

Model Driven Software Development con Eclipse, StatechartUMC Model Driven Software Development con Eclipse, StatechartUMC Aldi Sulova Istituto di Scienza e Tecnologie dell Informazione A. Faedo - CNR Via G. Moruzzi 1, 56124 Pisa, Italy aldi.sulova@isti.cnr.it Abstract.

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Statechart Diagrams Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Agenda Cosa è uno Statechart Diagram Quando

Dettagli

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Luciano Baresi Luciano Baresi 1 OMT Booch UML Sono simili in molti aspetti: Prescrivono un approccio passo-passo Consentono il passaggio dall analisi al progetto in modo omogeneo

Dettagli

Progettazione di Applicazioni Web

Progettazione di Applicazioni Web 1 Argomenti della lezione Progettazione di Applicazioni Web Sviluppo delle applicazioni Processo di sviluppo Formalismi grafici di supporto diagrammi UML (cenni) Scelta dell architettura Sviluppo di applicazioni

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE di Alessandro Spinelli Indice 1 - Introduzione 2 - Descrizione del problema 2.1 Requisiti funzionali 2.2 Requisiti non funzionali 3 - Analisi 3.1 Dizionario

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici. Informatica per la Logistica. Lezioni

Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici. Informatica per la Logistica. Lezioni Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici Le grandi e complesse organizzazioni aziendali sono la manifestazione tangibile della tecnologia avanzata, più delle

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

Progettazione del Software A.A.2008/09

Progettazione del Software A.A.2008/09 Laurea in Ing. Informatica ed Ing. dell Informazione Sede di latina Progettazione del Software A.A.2008/09 Domenico Lembo* Dipartimento di Informatica e Sistemistica A. Ruberti SAPIENZA Università di Roma

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab.

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab. Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Gli elementi che caratterizzano il Sistema Qualità e promuovono ed influenzano le politiche di gestione delle risorse

Dettagli

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio.

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio. Testo Esercizio Si consideri un sistema per la gestione di un magazzino di un negozio scelto a piacere dal candidato Il sistema è in grado di gestire le seguenti operazioni: Arrivo di nuovi prodotti; Controllo

Dettagli

Dominio applicativo. Analisi e ricognizione delle fonti dati

Dominio applicativo. Analisi e ricognizione delle fonti dati Dominio applicativo La Società chiamata StraSport, si occupa di vendite all ingrosso di articoli sportivi. Ha agenzie distribuite sul territorio italiano che gestiscono le vendite, ognuna di esse gestisce

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Sviluppo e Applicazioni Object Oriented Sviluppo e Applicazioni del Commercio Elettronico UML Analisi Object Oriented Programmazione Java

Sviluppo e Applicazioni Object Oriented Sviluppo e Applicazioni del Commercio Elettronico UML Analisi Object Oriented Programmazione Java Associazione Nazionale Aziende distributrici prodotti e servizi per l ufficio, l informatica e la telematica Via Merano, 18 20127 Milano-telefono (02) 28.500.91-telefax (02) 28.500.999 E-Mail: comuff@tin.it

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

DD - Design Document

DD - Design Document Politecnico di Milano Progetto di Ingegneria del Software 2 DD - Design Document Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 1 gennaio

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING

INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING Modulo propedeutico Le lezioni teoriche sono sviluppate sui seguenti argomenti: Struttura dell elaboratore: CPU,

Dettagli

UML e la progettazione di e-learning

UML e la progettazione di e-learning UML e la progettazione di e-learning Perché UML? UML (Unified Modeling Language, letteralmente: Linguaggio Unificato di Modellazione) viene spesso confuso come una metodologia per analizzare e progettare

Dettagli

Una metodologia per la specifica di software basato su componenti

Una metodologia per la specifica di software basato su componenti Luca Cabibbo Architetture Software Una metodologia per la specifica di software basato su componenti Dispensa ASW 445 ottobre 2014 La mappa non è il territorio. Douglas R. King 1 -Fonti [UML Components],

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA 1 Sistema Informativo Un sistema informativo (SI) è un componente di una organizzazione il cui obiettivo è gestire le informazioni utili per gli scopi dell

Dettagli

IL SISTEMA INFORMATIVO AZIENDALE

IL SISTEMA INFORMATIVO AZIENDALE IL SISTEMA INFORMATIVO AZIENDALE CL. 5ATP - A.S. 2006/2007 L azienda e i suoi elementi PERSONE AZIENDA BENI ECONOMICI ORGANIZZAZIONE L azienda è un insieme di beni organizzati e coordinati dall imprenditore

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Organizzazione aziendale Lezione 16 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28

Organizzazione aziendale Lezione 16 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Organizzazione aziendale Lezione 16 BPMN Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Nozioni di base Un sistema è una collezione di entità (es. persone o macchine) che interagiscono

Dettagli

Sistemi Informativi I Caso di studio con applicazione di UML

Sistemi Informativi I Caso di studio con applicazione di UML 9 CASO DI STUDIO CON APPLICAZIONE DI UML...2 9.1 IL CASO DI STUDIO...2 9.1.1 Il sistema attuale...2 9.2 IL PROBLEM STATEMENT...3 9.2.1 Formulazione del Problem statement per il caso proposto...3 9.3 USE

Dettagli

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati Corso di Access Modulo L2A (Access) 1.1 Concetti di base 1 Prerequisiti Utilizzo elementare del computer Concetti fondamentali di basi di dati 2 1 Introduzione Un ambiente DBMS è un applicazione che consente

Dettagli

La Progettazione Concettuale

La Progettazione Concettuale La Progettazione Concettuale Università degli Studi del Sannio Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica CorsodiBasidiDati Anno Accademico 2006/2007 docente: ing. Corrado Aaron Visaggio

Dettagli

Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari

Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari Il presente documento descrive gli obiettivi disciplinari

Dettagli

UML un linguaggio universale per la modellazione del software. Adriano Comai

UML un linguaggio universale per la modellazione del software. Adriano Comai UML un linguaggio universale per la modellazione del software Adriano Comai 2 Finalmente uno standard per l analisi e disegno OO? L'obiettivo è ambizioso. Lo Unified Modeling Language (UML) vuole essere,

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti Progettazione del Software L3.1 Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw (Basato su materiale didattico

Dettagli

Organizzazione aziendale Lezione 22 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28

Organizzazione aziendale Lezione 22 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Organizzazione aziendale Lezione 22 BPMN Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Prima di cominciare: Erasmus! Scadenza: 5 luglio 2012 Durata: min 3 max 12 mesi Dal 1 giugno 2012

Dettagli

Università degli studi dell Aquila Sistemi informativi aziendali

Università degli studi dell Aquila Sistemi informativi aziendali Università degli studi dell Aquila Sistemi informativi aziendali Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Contenuti Il Business Modelling. Analisi e Definizione dei Requisiti. Analisi Concettuale.

Dettagli

Alunni classi quarte Servizi Commerciali

Alunni classi quarte Servizi Commerciali UNITA DI APPRENDIMENTO 1bis Istruzione professionale: Indirizzo Servizi Commerciali Denominazione Gestione informatica dell Azienda, marketing on line e web marketing Utenti destinatari Alunni classi quarte

Dettagli

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA FIGURA

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

Dettagli

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO Modulo 1: IL LINGUAGGIO HTML Formato degli oggetti utilizzati nel Web Elementi del linguaggio HTML: tag, e attributi

Dettagli

Modellazione di processi

Modellazione di processi Luca Cabibbo Architetture Software Dispensa ASW 910 ottobre 2014 La modellazione è un mestiere e a volte è un arte. William C. Burkett 1 -Fonti [Papazoglou] Papazoglou, Web Services Principles and Technology,

Dettagli

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi.

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. PROGETTO SeT Il ciclo dell informazione Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. Scuola media Istituto comprensivo di Fagagna (Udine) Insegnanti referenti: Guerra Annalja, Gianquinto

Dettagli

ANNO SCOLASTICO 2014/2015. LICEO SCIENTIFICO STATALE A. VOLTA Via Juvarra, 14 - Torino

ANNO SCOLASTICO 2014/2015. LICEO SCIENTIFICO STATALE A. VOLTA Via Juvarra, 14 - Torino ANNO SCOLASTICO 2014/2015 LICEO SCIENTIFICO STATALE A. VOLTA Via Juvarra, 14 - Torino Obiettivi minimi Informatica Prime Conoscere il sistema di numerazione binaria e la sua importanza nella codifica delle

Dettagli

Sequence Diagram e Collaboration Diagram

Sequence Diagram e Collaboration Diagram Sequence Diagram e Collaboration Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Sommario Interaction

Dettagli

PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati

PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati L art. 27 decreto legge 24 aprile 2014 n. 66, convertito con modificazioni dalla legge 23 giugno 2014, n. 89, introduce significative

Dettagli

Fasi di creazione di un programma

Fasi di creazione di un programma Fasi di creazione di un programma 1. Studio Preliminare 2. Analisi del Sistema 6. Manutenzione e Test 3. Progettazione 5. Implementazione 4. Sviluppo 41 Sviluppo di programmi Per la costruzione di un programma

Dettagli

Sommario. Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi.

Sommario. Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi. Algoritmi 1 Sommario Definizione di informatica. Definizione di un calcolatore come esecutore. Gli algoritmi. 2 Informatica Nome Informatica=informazione+automatica. Definizione Scienza che si occupa dell

Dettagli

Ingegneria del Software: UML Class Diagram

Ingegneria del Software: UML Class Diagram Ingegneria del Software: UML Class Diagram Due on Mercoledì, Aprile 1, 2015 Claudio Menghi, Alessandro Rizzi 1 Contents Ingegneria del Software (Claudio Menghi, Alessandro Rizzi ): UML Class Diagram 1

Dettagli

PIANO di LAVORO A. S. 2014/ 2015 I.P.I.A. G. PLANA

PIANO di LAVORO A. S. 2014/ 2015 I.P.I.A. G. PLANA Nome docente Vessecchia Laura Materia insegnata T.I.C. Classe I A/B Manutenzione Ore complessive di insegnamento 2 ore sett. ( tot. 66) Clippy extra - Corso di informatica per il primo biennio - Vol.1

Dettagli

Progettazione base dati relazionale

Progettazione base dati relazionale Progettazione base dati relazionale Prof. Luca Bolognini E-Mail:luca.bolognini@aliceposta.it Progettare una base di dati Lo scopo della progettazione è quello di definire lo schema della base di dati e

Dettagli

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione Obiettivo della lezione Casi d uso La modellazione dei requisiti funzionali I casi d uso Gli attori Gli scenari Come scrivere casi d uso Casi d uso (use cases) Scenari d interazione Proposti da Ivar Jacobson

Dettagli