Nella letteratura sono state proposte diverse definizioni di legacy system; dall analisi

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Nella letteratura sono state proposte diverse definizioni di legacy system; dall analisi"

Transcript

1 LEGACY SYSTEM 1.1 Che cosa è un Legacy System Nella letteratura sono state proposte diverse definizioni di legacy system; dall analisi del termine legacy ( qualcosa di valore ricevuto dal passato ), si può considerare la seguente definizione: Un sistema (o applicazione) legacy è un sistema (o applicazione) informativo esistente da anni, che è di valore per il business da esso supportato, e che è stato ereditato dall'ambiente elaborativo attuale. In questa definizione, bisogna approfondire il significato dei termini valore e ereditato dal passato. Il primo è il riferimento alla logica di business dell organizzazione: quanto più la logica è insostituibile, tanto più il valore del sistema aumenta. Il secondo termine vuole indicare generalmente che il sistema che si prende in considerazione è già operativo, da almeno cinque anni. Le caratteristiche fondamentali di un legacy system sono: È un sistema mission-critical, cioè è fondamentale per l operatività dell organizzazione ed è costantemente utilizzato; Su di esso l organizzazione ha pesantemente investito nel corso degli anni, e quindi non può essere semplicemente accantonato così com è; È di grosse dimensioni, centinaia di migliaia di linee di codice, distribuite su migliaia di programmi;

2 Il suo nucleo risale ad un decennio fa ed è quindi progettato secondo vecchie concezioni; Può essere scritto in linguaggi di vecchia generazione, supportare DBMS obsoleti ed avere un interfaccia utente non grafica; Non è ben documentato ed è difficile da comprendere, poiché la documentazione non è aggiornata con le modifiche che via via sono state apportate; Il sistema è considerato come il repository di funzionalità aziendali non esplicitamente documentate. Molte applicazioni sviluppate negli anni 70 e 80 possono essere senz altro considerare esempi di Legacy System. Si tenga presente, che le caratteristiche sopra menzionate, possono essere caratteristiche anche d applicazioni di recente realizzazione. Un esempio estremo di sistema legacy è data da un espressione del tipo ogni applicazione che non sia sviluppata con tecnologie attuali è legacy. Questo per ribadire che quando si parla di Legacy System non bisogna pensare ad un dinosauro morente. 1.2 Tipologie di Legacy System I sistemi e le applicazioni legacy, dalla prospettiva del trattamento, possono essere classificati come:

3 1) Altamente Decomponibili: sono ben strutturati e presentano alcune caratteristiche fondamentali: a) I componenti applicativi sono separabili in logica di presentazione, logica applicativa e logica d accesso ai dati, cioè il software è composto di tre livelli logici; b) I moduli applicativi sono indipendenti tra loro; c) I moduli applicativi hanno interfacce ben definite con i servizi di database, quelli di presentazione e le altre applicazioni; 2) Data decomponibili: sono i cosiddetti semistrutturati con le seguenti caratteristiche fondamentali: a) I componenti applicativi sono separabili in due livelli: i servizi d accesso ai dati e quelli di presentazione e logica applicativa fusi in un solo blocco; b) I moduli applicativi hanno interfacce ben definite verso le altre applicazioni. In questi sistemi è possibile accedere direttamente ai dati, ma non alla logica applicativa. 3) Program decomponibili: sono anch essi semistrutturati con le seguenti caratteristiche fondamentali: a) I componenti sono separabili in due livelli: i servizi di presentazione e quelli di accesso ai dati e logica applicativa fusi in un unico blocco; b) I moduli applicativi hanno interfacce ben definite verso le altre applicazioni.in questi sistemi non è possibile accedere direttamente ai dati, ma necessario

4 invocare delle funzioni predefinite (tipicamente una transazione).in questa categoria rientrano la maggior parte delle applicazioni legacy; 4) Monolitici (non strutturati): sono i sistemi in cui tutti i componenti appaiono come un unico blocco in cui tutti i livelli logici fusi insieme.generalmente a questi sistemi si può accedere solo attraverso l invocazione da interfaccia grafica. Molte applicazioni in realtà hanno un architettura che è una combinazione di queste quattro. Dal punto di vista della facilità di trattamento, i Legacy System possono essere distinti in: Ostili: sono quelli che non permettono la possibilità d interfacciamento con l esterno; Trattabili: l interfacciamento con altri sistemi è possibile con un certo sforzo di programmazione e tecnologie a hoc; Amichevoli: l interfacciamento con altri sistemi è facilmente fattibile. Risulta evidente che i sistemi del primo tipo sono amichevoli, quelli data/program decomponibili sono trattabili, mentre quelli dell ultimo tipo sono ostili.

5 Fig. 0-1 Tipologie di Legacy System

6 1.3 Trattamento dei Legacy System Fino a qualche tempo fa l unica attività operativa legata in particolar modo ad un sistema Legacy era la manutenzione, sia evolutiva, sia correttiva. L elevato costo della manutenzione per questi sistemi, ha però portato, negli ultimi tempi, alla valutazione di possibili alternative per il trattamento dei sistemi Legacy: Esclusione: si esclude il sistema da ogni successivo sviluppo. È una soluzione non praticabile se il sistema contiene un alto valore Sostituzione Netta: si riscrive il sistema completamente da zero. Può essere valida se il sistema non è mission-critical. Migrazione graduale: si opera una trasformazione del sistema in maniera graduale. Integrazione: si consolida il sistema nelle sue funzionalità e si effettua il wrapping [cfr. par ] con tecnologie ad hoc. Tra queste si può fare una prima distinzione a seconda se l obiettivo sia la sostituzione con un nuovo sistema, o il mantenimento di gran parte del sistema opportunamente adattato con nuovi servizi e nuove tecnologie. Questo, ovviamente dipende dal valore che l azienda attribuisce al sistema, in termini di servizi forniti e criticità. Ultimamente si sta diffondendo una procedura differente, che può essere in parte considerata come un evoluzione dell approccio di sostituzione incrementale: l integrazione dei Legacy System basato sulle tecnologie abilitanti della Distributed Object Computing [cfr. Cap 2].

7 Fig. 0-2 Trattamento dei Legacy System Nella pratica, anche se si cerca di mantenere uno o l altro approccio di trattamento, spesso non si ha una netta distinzione applicativa; l utilizzo di approcci validi per il raggiungimento dello scopo, può contenere metodologie dell uno o dell altro approccio Sostituzione Netta: Approccio Cold Turkey Per sostituzione netta s intende la riscrittura dell intero sistema legacy, utilizzando metodologie, tecniche e tecnologie moderne. Quest approccio comporta però dei grossi rischi: Le esigenze dell organizzazione non stanno ad aspettare: lo sviluppo di un sistema richiede anni, e nel frattempo emergono nuovi bisogni informativi per l organizzazione ed in base a loro il legacy viene modificato; è evidente che deve modificato anche il nuovo sistema. Il rischio è in questa continua modifica durante lo sviluppo. Esistono raramente delle specifiche: talvolta la sola documentazione per il sistema è il codice stesso ed inoltre spesso tale codice è altamente specifico ( per motivi di prestazioni) per una macchina su cui è o era destinato a girare; ne

8 consegue che è molto difficile ricostruire le specifiche. Inoltre c è il problema delle dipendenze non documentate: inevitabilmente nel corso degli anni varie applicazioni, critiche o meno, si sono appoggiate alò sistema per informazioni o servizi; se questo va riscritto sarebbe auspicabile trovare queste informazioni da qualche parte, per non far saltare l operatività di tante applicazioni di contorno; spesso non c è una chiara consapevolezza di ciò e l individuazione è assai difficile. Il sistema legacy può essere troppo grande perché interrompa il suo accesso ai dati: molti sistemi devono essere operativi al 100% del tempo, mentre il travaso dei dati dal vecchio al nuovo sistema richiede settimane per essere attuato: spesso i dati, non solo devono essere travasati, ma anche ripuliti, controllati nella loro qualità e convertiti per aderire al nuovo sistema; inoltre, se il legacy dataserver non fornisce funzioni di download e l accesso ai dati avviene attraverso il sistema stesso, aumenta ancora di più il tempo di scaricamento degli stessi. In ogni caso si tratta di tempi che non sono compatibili con le esigenze dell organizzazione. La gestione di grandi progetti è rischiosa: il vecchio sistema ha un adimensione tale che costruire l equivalente dal nulla, corrisponde ad un progetto di grandissime dimensioni. Progetti di tali dimensioni hanno altissime probabilità di fallimento: sono generalmente sottostimati molti fattori, quali la complessità di ripartizione del lavoro, di formazione del personale di sviluppo e di gestione, etc. Tutto ciò non fa che aumentare le paure e le incertezze legate a quest approccio; se a questo si aggiunge la naturale indisposizione del management dell organizzazione a reinvestire tutto quello che ha gia investito per decenni, per avere un sistema con

9 le stesse funzionalità, ma con nuove tecnologie, si arriva all impraticabilità del processo, tanto che le organizzazioni preferiscono il tranquillo dinosauro legacy La Migrazione Una migrazione avviene tra un sistema esistente, detto souce, ed uno nuovo, detto target, dove il souce è tipicamente un sistema legacy ed il target è un sistema sviluppato secondo nuovi paradigmi e tecnologie. Per condurre una migrazione sono possibili differenti strategie: Migrazione parziale. Migrazione completa Migrazione parziale. Solo una parte del sistema viene trasformata, tipicamente quella che da maggiori problemi (alti costi di manutenzione, scarsa flessibilità, etc.); questa è una soluzione fattibile con rischi contenuti soprattutto per quei sistemi legacy del tipo amichevole o trattabile. Si agisce principalmente sulle interfacce utenti o sui dati Migrazione delle interfacce utenti Spesso il sistema ha bisogno solamente di presentarsi con un interfaccia utente migliore: non più quella a caratteri tipica dei terminali 3270, ma una GUI o meglio ancora un interfaccia Web accessibile da un browser. Si parla in questo caso di revamping, vale a dire effettuare un operazione di ripulitura della parte esterna del sistema, e quindi l interfaccia utente, lasciando il più possibile inalterato il cuore del sistema. In molti casi, infatti, basta mettere il sistema su internet per ottenere già un notevole miglioramento per il business dell organizzazione, in quanto si offrirebbe lo stesso servizio, ma raggiungibile più facilmente da molti utenti. La tecnologia offre allora una serie di strumenti midleware con cui diventa quasi immediato offrire con

10 una nuova veste la vecchia interfaccia sul Web; si tratta degli screen scraper, emulatori di terminali, con cui si permettono alle applicazioni client di simulare la pressione dei tasti e la lettura/scrittura di posizioni specifiche dello schermo fornendo delle interfacce per le funzionalità. Questa tecnologia non richiede alcun intervento sul sistema legacy, ma soffrono di problemi di prestazioni. Chiaramente una scelta migliore è quella di sostituire l interfaccia utente, riscrivendola. Ma questo è possibile solo nel caso di sistemi altamente decomponibili o program decomponibili. Nella pratica si adotta un approccio misto, quindi inizialmente, con lo screen scraping, si offre subito la nuova interfaccia e nello stesso tempo si comincia la riscrittura delle nuove interfacce. Al termine della scrittura di queste ultime, le vecchie interfacce e quelle intermedie ottenute dallo screen scraping, sono eliminate Migrazione dei dati La migrazione dei dati consiste nel trasferire i dati da una piattaforma ad un altra. Quest operazione, implica la soluzione di molti problemi: Conversione: ad esempio si passa da un database non relazionale a relazionale; Trasformazione: ad esempio creazione di nuove viste; Spostamento: ad esempio da un database su mainframe ad uno su UNIX; Allocazione: ad esempio da un database centralizzato ad uno distribuito. Esistono varie tecnologie di supporto alla migrazione dei dati, di complessità, potenza e disponibilità differenti:

11 Database Unload/Reload Utilities: sono utilità offerte dai DBMS, anche quelli legacy, che permettono di scaricare i dati in un formato piatto, come un file sequenziale, che è ricaricato dai DBMS target. I problemi nascono solo dal formato del file o del paradigma differente (ad esempio da DMBS source gerarchico a DBMS target relazionale); sono facilmente superabili con apposite routine scritte ad hoc. Tools di conversione automatica: tentano di risolvere i problemi di tipo generale, quale la conversione da un formato gerarchico ad uno relazionale. Possono includere editor per eventuali programmi d integrazione per risolvere quei problemi tipici del singolo caso. Data Propagators, Replication Servers e Gateway: forniscono strumenti per la migrazione graduale, nel periodo di transizione. L effettiva disponibilità sul mercato è limitata dalle funzionalità che offrono; anche in questo caso risulta necessario un pesante lavoro di sviluppo per programmi ad hoc Migrazione completa Una migrazione completa del sistema legacy è un processo che può richiedere anni e presentare rischi notevoli; proprio per questo l approccio graduale mantiene costantemente operativo il vecchio sistema e allo stesso tempo sviluppa, con piccoli passi incrementali, le varie porzioni del nuovo fino a che la sostituzione non sia totale (obiettivo di lungo termine). Ogni passo richiede un impiego di risorse relativamente basso, in termini di impiego di risorse e di tempo: riproduce così un piccolo risultato nella direzione dell obiettivo ed un controllo del rischio, in quanto se un passo fallisce, deve essere ripetuto solo quello, con riduzione di spese e di tempo contenute. L aspetto fondamentale per una migrazione graduale di successo, è

12 l individuazione della dimensione e indipendenza degli incrementi, la loro sequenza e correlazione Uno strumento: i gateway La migrazione graduale seleziona e sostituisce parti del vecchio sistema per diventare parti del sistema target incrementalmente costruito. Durante questo processo i due sistemi formano un sistema composito, che complessivamente implementa le funzionalità mission-critical. Nel sistema composito, souce e target sono connessi da un gateway, cioè da un modulo software introdotto tra i vari componenti operativi, per mediare tra loro. I ruoli fondamentali di un gateway sono: Isolare determinati componenti dagli effetti dei cambiamenti sugli altri: un gateway mantiene l interfaccia che il souce si aspetta da un determinato componente, che è stato sostituito o modificato, oppure isola un componente che non è stato ancora modificato dal resto del sistema target; Traduttore di richieste e dati: un gateway traduce richieste in un formato standard per servire sia moduli legacy sia target; Coordinatore tra i componenti per mantenere la consistenza nelle interrogazioni e degli aggiornamenti: è possibile che i dati o le funzioni che implementano l interrogazione o l aggiornamento, siano stati parzialmente o completamente decomposti in componenti del source e migrati in componenti target; inoltre ci possono essere copie replicate di dati e funzioni. Il gateway deve allora decomporre correttamente la forma di accesso nelle sue sottoforme da presentare alla funzione o ai dati opportuni e poi raccoglierne ed integrarne gli effetti con coerenza e consistenza; il compito più difficile dal punto di vista della

13 coordinazione riguarda gli aggiornamenti e può essere dominato solo con tecnologie database avanzate. Una volta individuato il problema nella specifica situazione, poiché esistono pochi gateway commercialmente disponibili validi, l unica soluzione è sviluppare applicazioni dedicate. Il posizionamento di un gateway è un fattore critico per la complessità di una migrazione: Database gateway: il gateway può essere messo tra i moduli applicativi ed i servizi database, incapsulando l intero database rispetto alle applicazioni; Fig. 0-3 Posizionamento Gateway : DataBase Gateway Application gateway: il gateway può essere messo tra lo strato di presentazione e il resto del sistema; System gateway: il gateway può incapsulare l intero sistema.

14 Fig. 0-4 Posizionamento Gateway: Application Gateway Fig. 0-5 Posizionamento Gateway: System Gateway In genere, più in alto è posizionato il gateway, più funzionalità deve incapsulare e più risulta complesso. Da un punto di vista strutturale, un gateway ha due componenti fondamentali utili durante la migrazione: Forward gateway permettono alle applicazioni legacy di accedere ai dati nella parte target del sistema;

15 Riverse gateway permettono alle applicazioni target di accedere ai dati nell ambiente legacy Architetture per la migrazione I sistemi altamente decomponibili sono i più facili da migrare: ogni componente ha interfacce ben definite e quindi può gradualmente essere sostituito durante il processo di migrazione. Questo può procedere secondo due direzioni od un misto delle due: Migrare il database legacy per primo, e successivamente migrare la logica applicativa e quella di presentazione. Le tecnologie e le tecniche sono quelle utilizzate nel caso della migrazione parziale dei soli dati; il gateway in questo caso è un "forward database gateway". Migrare il database legacy per ultimo, dopo che si è migrato la logica di presentazione e quell'applicativa. Questo è particolarmente valido quando la necessità fondamentale è quella di offrire un'interfaccia più moderna e nuove funzionalità di business, oppure quando il database è troppo grande per essere migrato all'inizio. Il gateway è di tipo "reverse database gataway". Nella pratica sono utilizzati contemporaneamente entrambe le strategie, per cui il gateway presenta sia funzionalità di forward che reverse. Le stesse strategie possono essere utilizzate anche nel caso di sistemi data decomponibili, anche se il passo di migrazione delle logiche applicative e di presentazione è più complesso. Per i sistemi program decomponibili (e questa è la stragrande maggioranza dei casi concreti), il gateway deve incapsulare tutta la logica sottostante rispetto a quella di presentazione, e si presenta come un application gateway. Per questo tipo di sistemi

16 possiamo o migrare prima la logica di presentazione (reverse gateway) o migrare prima il resto del sistema (forward gateway). Nel caso di sistemi monolitici, il gateway diventa un sistema un system gateway, attraverso cui devono passare tutte le richieste d'accesso al sistema (sia richieste di utenti che di altri sistemi), ed esso le smista al nuovo o vecchio sistema. Chiaramente questo tipo di gateway è abbastanza complesso da costruire ed il caso più difficile e rischioso da affrontare Una metodologia: l'approccio Chicken Little L'approccio Chicken Little è una metodologia di migrazione incrementale che si basa sulla migrazione per piccoli passi successivi finché non è raggiunto l'obiettivo finale. Ogni passo di migrazione può essere agevolmente dimensionato alle risorse di cui l'organizzazione dispone per la sua esecuzione. Piccoli passi di migrazione producono risultati specifici e non stravolgono l'ambiente di lavoro; sia il management aziendale, sia gli utenti del sistema legacy sono più disposti a collaborare per il successo del singolo passo di migrazione. Inoltre, si può controllare il rischio scegliendo la dimensione del passo di migrazione; minore è l'incremento di migrazione, minore è il rischio d'insuccesso, ma minore è anche il vantaggio che se ne può trarre. Nell'approccio, ogni passo di migrazione deve riguarda un aspetto specifico della migrazione. Si può avanzare, contemporaneamente, con più passi purché questi riguardino aspetti indipendenti del sistema legacy. In caso di insuccesso di un passo di migrazione, solo quest'ultimo è ripetuto. Ci sono quattro principali fasi iniziali di un progetto di migrazione secondo l'approccio Chicken Little:

17 1. Ridurre la quantità di dati e funzioni del sistema legacy. Molti dati possono essere duplicati, nei files o nei databases del sistema legacy, e molte porzioni di codice possono essere ripetute nei vari moduli applicativi. I moderni DBMS relazionali risolvono il problema della ridondanza dei dati, così anche alcune funzioni che li elaborano possono essere, di conseguenza, inutili: minori sono i dati utili non dupicati, minore è lo sforzo delle loro gestione e maggiore è l'efficienza della loro elaborazione. 2. E' impossibile dettagliare tutte le fasi del progetto se, fin dall'inizio, si sa che il completamento del progetto richiederà alcuni anni. Le ragioni di tale impossibilità sono almeno due: Il sistema legacy è troppo grande e/o convoluto per poterlo analizzare nei dettagli per intero; alcuni di questi saranno scoperti solo quando il sistema legacy è già parzialmente migrato. Uno o più cambiamenti dei requisiti commerciali possono richiedere l'introduzione di nuove funzionalità nel sistema legacy. Pertanto si sviluppa un progetto di alto livello relativo all'intera migrazione e poi, su richiesta dell'organizzazione, si sviluppa un progetto dettagliato del singolo passo di migrazione. 3. Si progetta l'ambiente target usufruendo delle nuove tecnologie HW e SW. L'ambiente target deve essere flessibile, cioè portabile, per rendere il sistema target adattabile alle modifiche che il progresso tecnologico e i cambiamenti dei requisiti aziendali impongono per rimanere competivi.

18 4. Si progetta il "framework" di migrazione includendo il sistema legacy, il sistema target e il sistema composito (tipicamente dei gateway). In questa fase devono essere presi in considerazioni le interfacce, le funzioni e i dati. Anche in questo caso si dettaglia una porzione del progetto d'alto livello solo quando l'organizzazione è pronta ad affrontarlo. I passi di migrazione dell'approccio Chicken Little sono i seguenti: 1. Analisi incrementale del sistema legacy. 2. Decomposizione incrementale della struttura del sistema legacy. 3. Progetto incrementale delle interfacce target. 4. Progetto incrementale delle applicazioni target. 5. Progetto incrementale del DB target. 6. Installazione incrementale dell'ambiente target. 7. Creazione ed installazione incrementale dei gateway necessari. 8. Migrazione incrementale del DB legacy. 9. Migrazione incrementale delle applicazioni legacy. 10. Migrazione incrementale delle interfacce legacy. 11. "Cut - Over" incrementale al sistema target.

19 Fig. 0-6 Passi di una migrazione Chicken Little Dalla figura 6 risulta chiaro che esiste la possibilità di far avanzare parallelamente alcuni passi di migrazione in ogni incremento. Specificamente i passi etichettati con 1, 3, 4, 5, 6 possono compiersi contemporaneamente. Il passo 2 (decomposizione del sistema legacy), presuppone che sia già completo il passo 1 (analisi del sistema legacy relativamente al corrente incremento di migrazione). Il passo 7 può procedere parallelamente ai.passi 8, 9 e 10 solo dopo aver concluso i passi da 1 a 6. Solo al termine dei 10 passi si effettua il passo finale Descrizione dei passi dell'approccio Chicken Little Descriviamo i passi dell'approccio: 1. Analisi incrementale del sistema legacy. Il primo passo per la migrazione di un sistema legacy è capire quali sono le sue funzioni, come sono realizzate, quali

20 legami esistono fra loro, quali sono quelle critiche, etc. Nella maggioranza dei casi non esiste documentazione d'alcun genere relativa alle fasi alte di progetto del sistema e, se esiste, non è aggiornata. Quindi il sistema legacy deve essere sottoposto ad un processo di reverse engineering per avere delle rappresentazioni del sistema ad un livello d'astrazione più alto. Poiché è impossibile raggiungere una dettagliata conoscenza del sistema, occorre focalizzarsi soltanto su alcuni aspetti del sistema e rimandare l'approfondimento degli altri incrementi ai successivi incrementi di migrazione. 2. Decomposizione incrementale della struttura del sistema legacy: si effettuano modifiche al sistema per assicurarsi che sia decomponibile; individuate le dipendenze tra le interfacce, le applicazioni ed i dati, si eliminano. Queste modifiche sono necessarie, possono però incidere negativamente sulla prestazione del sistema stesso. E' bene non dedicare troppe energie per le suddette modifiche perché i "moduli legacy" saranno sostituiti. 3. Progetto incrementale delle interfacce target. Premettendo che le interfacce, sia di sistema sia utente, sono tanto importanti in un sistema quanto lo sono le applicazioni ed i servizi di gestione dei dati, occorre effettuare il progetto e la pianificazione della strategia di migrazione delle interfacce e decidere se usare un gateway. 4. Progetto incrementale delle applicazioni target. Premesso che le applicazioni saranno in esecuzione sulla piattaforma target, devono essere progettate secondo le business rules che l'ambiente target deve supportare. Le applicazioni target o sono derivate da un reengineering del sistema legacy o sono fornite da prodotti SW commerciali che dimostrano di soddisfare, in modo congruo, gli

21 stessi requisiti soddisfatti dalle applicazioni legacy. I rischi di questo passo sono aumentati dalla quasi immancabile richiesta che nuovi requisiti siano soddisfatti. 5. Progetto incrementale del DB target. Il nuovo sistema avrà un DBMS relazionale (molto probabilmente distribuito oppure object oriented) per elaborare e memorizzare i dati. Innanzi tutto si deve scegliere tra i vari prodotti commerciali simili e, quando il DBMS è stato scelto, progettare lo schema relazionale soddisfacente i requisiti dei dati coinvolti nell'incremento di migrazione. Il punto cruciale di questo passo di migrazione è che le applicazioni legacy racchiudono le definizioni dei dati; solitamente, esse sono distribuite in tutto il codice dell'applicazione legacy. La ricerca delle definizioni dei dati è complicata dal probabile aliasing e quella del significato e dell'utilità dalle cattive pratiche di naming. Attualmente esiste la tendenza, accentuata dal paradigma di programmazione object oriented, a racchiudere la definizione dei dati e I'implementazione delle funzioni che li manipolano in specifici moduli SW. 6. Installazione incrementale dell'ambiente target. I requisiti che il nuovo sistema deve soddisfare, determinano i requisiti dell'ambiente target. In effetti, è meglio identificare l'ambiente target indipendentemente dai requisiti per evitare di ottenere una soluzione troppo specifica alla realtà organizzativa dell'impresa. La vera intenzione è di avere un sistema target flessibile, in primo luogo, che debba soddisfare i nuovi requisiti. 7. Creazione ed installazione incrementale dei gateway necessari. Questo è il passo in cui si avvertono maggiormente le sfide poste dalla migrazione. Il tipo di gateway che deve essere realizzato (o comprato, se si trova in commercio quello che soddisfa i requisiti) dipende dall'architettura del sistema legacy.

22 8. Migrazione incrementale del DB legacy. La quantità di dati e le funzionalità operative del sistema legacy impediscono la migrazione complessiva di tutti i dati. Dopo aver installato il DB scelto nel passo 5 e prima di memorizzare i dati dal DB legacy, i dati devono essere vagliati per eliminare quelli inutili (tra questi quelli ridondanti). Questo passo è effettuato con l'ausilio di gateway per supportare le chiamate delle applicazioni legacy. Data l'enormità di dati, se si scegli un approccio incrementale, si complicano le funzionalità del gateway. 9. Migrazione incrementale delle applicazioni legacy. Sono selezionati e fatti migrare uno o più moduli secondo criteri tecnici ed organizzativi (semplicità, costi, priorità), sviluppandoli in modo tale che possano interagire direttamente con il nuovo DBMS. 10.Migrazione incrementale delle interfacce legacy. Usando criteri analoghi a quelli del passo precedente, sono selezionate e migrate nel nuovo ambiente una o più interfacce legacy. La selezione avviene in coordinazione con quella delle applicazioni. Per il resto valgono le considerazioni del punto precedente. 11."Cut-Over" incrementale al sistema target. Il termine "cut-over" indica il processo con cui si passa da uno stato, nel quale le operazioni sono fatte ancora dal sistema legacy, a quello in cui sono fatte direttamente dal sistema target. Poiché i moduli target possono essere pronti mesi e, forse anche, anni prima che il sistema target sostituisca del tutto il legacy, si possono avere problemi di gestione di configurazione e controllo della versione. I singoli passi di questo processo possono essere incrementali, riducendo ulteriormente i rischi di un eventuale taglio netto del singolo passo. Quando nessun

23 elemento del sistema legacy è più operativo, il sistema e il suo ambiente saranno eliminati Integrazione Integrare significa usare il sistema e i dati legacy nel più ampio contesto del business e della sua architettura informativa. L'obiettivo principale è ottenere la logica di business, i processi e le informazioni del sistema legacy, senza l'importare da questo le tecnologie e metodologie del passato. L'integrazione nasconde (incapsula) il sistema legacy dietro interfacce consistenti, che si riferiscono ai processi di business, nascondendo i dettagli implementati e facendo cooperare il sistema con gli altri sistemi dell'organizzazione, soprattutto con quelli d'ultima generazione. Per ottenere questo, si decompone il sistema in componenti detti "sevices based" e si partizionano i processi di business in domini distinti ma cooperanti. Per ripartire il sistema legacy, è necessario capirne il contenuto e quindi implementare delle interfacce astratte che rendono i domini e i processi disponibili agli altri I wrapper Il concetto di wrapper è semplice: si tratta di un livello di software che nasconde l'implementazione effettiva delle funzionalità del legacy e le presenta attraverso uninterfaccia ben definita; quest'ultima è tipicamente ad oggetti, in modo che all'esterno il sistema legacy appaia con una veste nuova di più oggetti, simili ad altri oggetti (nuovi) e operanti nello stesso ambiente, accettando e rispondendo con gli stessi messaggi degli altri oggetti come se fossero nuovi. In questo modo, poiché le applicazioni legacy implementano i processi fondamentali di business, il wrapper ad oggetti alza il livello d'astrazione al livello d'oggetti di business, permettendo una facile integrazione con il resto del nuovo sistema. I requisiti di un buon wrapper sono:

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

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

IL TRATTAMENTO DEI LEGACY SYSTEM. Antonio Massari, Massimo Mecella

IL TRATTAMENTO DEI LEGACY SYSTEM. Antonio Massari, Massimo Mecella IL TRATTAMENTO DEI LEGACY SYSTEM Antonio Massari, Massimo Mecella 1. Introduzione ai Legacy System 1.1. Cosa è un Legacy System Secondo il Webster si definisce legacy something of value received from an

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

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

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Tecnologie per lo sviluppo di applicazioni La tendenza attuale dell'ingegneria è quella dell'integrazione di componenti

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Versione Preliminare Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2008-2009 Questi

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

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

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Data Warehousing e Data Mining

Data Warehousing e Data Mining Università degli Studi di Firenze Dipartimento di Sistemi e Informatica A.A. 2011-2012 I primi passi Data Warehousing e Data Mining Parte 2 Docente: Alessandro Gori a.gori@unifi.it OLTP vs. OLAP OLTP vs.

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

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

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2 DIB 1 Sommario Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 2 Architettura a 3 Livelli DIB 3 Architettura a 3 Livelli Presentazione Gestione dell interazione degli

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015 BASE DI DATI: introduzione Informatica 5BSA Febbraio 2015 Di cosa parleremo? Base di dati relazionali, modelli e linguaggi: verranno presentate le caratteristiche fondamentali della basi di dati. In particolare

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

Guida al livellamento delle risorse con logica Critical Chain (1^ parte)

Guida al livellamento delle risorse con logica Critical Chain (1^ parte) Paolo Mazzoni 2011. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2011". Non sono ammesse

Dettagli

Data Warehouse Architettura e Progettazione

Data Warehouse Architettura e Progettazione Introduzione Data Warehouse Architettura! Nei seguenti lucidi verrà fornita una panoramica del mondo dei Data Warehouse.! Verranno riportate diverse definizioni per identificare i molteplici aspetti che

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

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Le Infrastrutture Software ed il Sistema Operativo

Le Infrastrutture Software ed il Sistema Operativo Le Infrastrutture Software ed il Sistema Operativo Corso di Informatica CdL: Chimica Claudia d'amato claudia.damato@di.uniba.it Il Sistema Operativo (S0) (Inf.) E' l'insieme dei programmi che consentono

Dettagli

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES è una metodologia per implementare rapidamente sistemi informativi aziendali complessi,

Dettagli

Automazione Industriale 4- Ingegneria del Software

Automazione Industriale 4- Ingegneria del Software Automation Robotics and System CONTROL Università degli Studi di Modena e Reggio Emilia Automazione Industriale 4- Ingegneria del Software Cesare Fantuzzi (cesare.fantuzzi@unimore.it) Ingegneria Meccatronica

Dettagli

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o Navigare verso il cambiamento La St r a d a p i ù semplice verso il ca m b i a m e n t o Le caratteristiche tecniche del software La Tecnologia utilizzata EASY è una applicazione Open Source basata sul

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Corso Web programming

Corso Web programming Corso Web programming Modulo T3 A1 Modelli di programmazione 1 Prerequisiti Concetto di rete Processi e thread Concetti generali sui database 2 1 Introduzione Un particolare ambito della programmazione

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Introduzione ai Sistemi Operativi

Introduzione ai Sistemi Operativi Introduzione ai Sistemi Operativi Sistema Operativo Software! Applicazioni! Sistema Operativo! È il livello di SW con cui! interagisce l utente! e comprende! programmi quali :! Compilatori! Editori di

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Annuncio software IBM per Europa, Medio Oriente e Africa ZP09-0108, 5 maggio 2009

Annuncio software IBM per Europa, Medio Oriente e Africa ZP09-0108, 5 maggio 2009 ZP09-0108, 5 maggio 2009 I prodotti aggiuntivi IBM Tivoli Storage Manager 6.1 offrono una protezione dei dati e una gestione dello spazio migliorate per ambienti Microsoft Windows Indice 1 In sintesi 2

Dettagli

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi : di base e applicativo L HardWare (monitor, tastiera, circuiti, stampante, ) è il nucleo fondamentale del calcolatore ma da solo non serve a nulla. Bisogna utilizzare il software per poterlo fare funzionare.

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Servizi di connessione Prodotti a supporto del business Per sfruttare al meglio una rete di ricarica per veicoli

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

MODERNIZZAZIONE APPLICAZIONI

MODERNIZZAZIONE APPLICAZIONI MODERNIZZAZIONE APPLICAZIONI IL PROBLEMA Per molte aziende c è la necessità di integrare o aprire i processi alle nuove tecnologie che evolvono sempre più rapidamente. Spesso capita che l azienda ha dei

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

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

Progettazione di un db. Basi di Dati II. Large Database. Il ruolo dei Sistemi Informativi in un azienda

Progettazione di un db. Basi di Dati II. Large Database. Il ruolo dei Sistemi Informativi in un azienda Progettazione di un db Basi di Dati II Lezione 3: Applicazioni di design & tuning di database Prof.ssa G. Tortora a.a. 2004/2005 1 Abbiamo già visto in dettaglio gli aspetti teorici di progettazione di

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

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

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

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

Software Testing. Lezione 2 Livelli di test. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Rabini/F.Spiga

Software Testing. Lezione 2 Livelli di test. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Rabini/F.Spiga Software Testing Lezione 2 Livelli di test Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: F.Rabini/F.Spiga 1 2 Livelli di test Unit Testing Integration Testing System Testing Unit Testing

Dettagli

CONTENT MANAGMENT SYSTEMS

CONTENT MANAGMENT SYSTEMS CONTENT MANAGMENT SYSTEMS ESTRATTO DA: Ileana D'Incecco, Progettare la comunicazione web per organizzazioni non-profit con strumenti open source: ideazione e realizzazione del sito web della Casa delle

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli

Software per la gestione di musei di arte contemporanea1

Software per la gestione di musei di arte contemporanea1 Software per la gestione di musei di arte contemporanea1 Identificativo del progetto: CA Nome documento: System Design(SD) Identificativo del documento: 6 CA_SD_E1_R1 Data del documento: 21/05/2012 Prima

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

LINUX. Che cos'e` un sistema operativo?

LINUX. Che cos'e` un sistema operativo? LINUX LINUX Introduzione Una versione completa e affidabile di UNIX Disponibile per PC x86 Intel/AMD e numerose altre piattaforme Strumento (quasi) indispensabile per le esercitazioni Include gli strumenti

Dettagli

Sistemi centralizzati e distribuiti

Sistemi centralizzati e distribuiti Sistemi centralizzati e distribuiti In relazione al luogo dove è posta fisicamente la base di dati I sistemi informativi, sulla base del luogo dove il DB è realmente dislocato, si possono suddividere in:

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

Allegato 2: Prospetto informativo generale

Allegato 2: Prospetto informativo generale Gara a procedura ristretta accelerata per l affidamento, mediante l utilizzo dell Accordo Quadro di cui all art. 59 del D.Lgs. n. 163/2006, di Servizi di Supporto in ambito ICT a InnovaPuglia S.p.A. Allegato

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

Tecnologia dei Sistemi Informativi. architettura s.i. 1

Tecnologia dei Sistemi Informativi. architettura s.i. 1 Tecnologia dei Sistemi Informativi architettura s.i. 1 Sistema Informativo comprende risorse umane è fortemente integrato con il sistema organizzativo è essenziale per il funzionamento dell'azienda architettura

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

Introduzione ai database I concetti fondamentali Database e DBMS Per comprendere appieno cos'è un Database e quali sono i vantaggi legati al suo impiego, soprattutto nel settore gestionale, è necessario

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Guida rapida all uso di Moodle per i docenti

Guida rapida all uso di Moodle per i docenti Guida rapida all uso di Moodle per i docenti Avvertenze: 1) Questo NON è un manuale completo di Moodle. La guida è esplicitamente diretta a docenti poco esperti che devono cimentarsi per la prima volta

Dettagli

Basi di Dati prof. A. Longheu. 5 Progettazione fisica

Basi di Dati prof. A. Longheu. 5 Progettazione fisica Basi di Dati prof. A. Longheu 5 Progettazione fisica Progettazione Fisica Per effettuare la progettazione fisica, ossia l implementazione reale del modello logico creato nella fase della progettazione

Dettagli

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI.

CON LA CARTA DEI SERVIZI, I NOSTRI UTENTI SONO SEMPRE AL CENTRO DELLE NOSTRE ATTENZIONI. CARTA DEI SERVIZI La qualità del servizio nei confronti dell Utente e la soddisfazione per l utilizzo delle soluzioni sono obiettivi strategici per Sistemi. Le soluzioni software Sistemi, siano esse installate

Dettagli

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo F.O.A.M. Free Object Access Method Un introduzione Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo Il protocollo FOAM. FOAM (Free Object Access Method) è un protocollo

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

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5.1. Introduzione Due macchine si parlano solo se conoscono l'indirizzo fisico di sottorete Due applicazioni si parlano solo se conoscono

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli