|
Categorie
Winzipedia Uso dell'wiki |
ProgettazioneIngegneriaDelSoftware.Progettazione VersioniMostra le modifiche minori - Mostra le modifiche Modificata la linea 8: da:
dei requisiti. Lo scopo della progettazione del software a:
dei requisiti. Lo scopo della progettazione del software quello di applicare Modificata la linea 10: da:
sviluppo di un sistema di . della progettazione a:
sviluppo di un sistema di . della progettazione quello di Modificata la linea 26: da:
* Riuso , il codice esistenze a:
* Riuso , il codice esistenze corretto, si risparmiano tempo e costi Modificata la linea 28: da:
Il ruolo durante la fase di progettazione a:
Il ruolo durante la fase di progettazione quello di unire Modificata la linea 33: da:
Il documento di progettazione a:
Il documento di progettazione il risultato della progettazione e prende il Modificate le linee 38-39: da:
* Dettagli esecutivi, In alcune aziendali il documento di progettazione non a:
* Dettagli esecutivi, delle linee da seguire per . In alcune aziendali il documento di progettazione non usato Modificata la linea 43: da:
esiste. Capita spesso che il progetto a:
esiste. Capita spesso che il progetto costruito a posteriori per questioni Modificata la linea 45: da:
mesi il progetto reale a:
mesi il progetto reale diventato completamente diverso. bene distinguere Modificata la linea 59: da:
di un prodotto software a:
di un prodotto software descritta da aspetti (viste) Modificate le linee 71-72: da:
* ''Astrazione'', il sistema viene suddiviso in livelli differenti di astrazione. Al livello alto la soluzione * ''Modularizzazione'', il sistema a:
* ''Astrazione'', il sistema viene suddiviso in livelli differenti di astrazione. Al livello alto la soluzione espressa a grandi linee, nel linguaggio del contesto del problema. Ai livelli bassi si adotta una descrizione dettagliata. A mano a mano che si procede a livelli differenti di astrazione, si creano astrazioni procedurali e astrazioni relative ai dati. Si sfruttano tecniche di e polimorfismo. * ''Modularizzazione'', il sistema diviso in diversi moduli, ognuno con compito specifico. La modularizzazione permette facilmente di suddividere lo sforzo tra i vari programmatori. Ogni modulo essere testato singolarmente e, quando funzionante in modo corretto, integrato nel sistema. Il tutto implica una definizione a priori dei moduli, delle loro funzioni e delle interfacce per una corretta integrazione. Criterio di modularizzazione di Myers (1974) definisce un modello di : massimizzare la coesione, minimizzare . Modificate le linee 75-77: da:
** Flusso di controllo, tramite frecce ** Flusso dei dati, tramite frecce * Coesione, per coesione di un componente si intende un modulo che realizza una o funzioni simili (Esempio: modulo di visualizzazione delle immagini) e quindi, in caso di errore (esempio visualizzata male) a:
** Flusso di controllo, tramite frecce possibile indicare quale modulo usa i dati di modulo (Esempio: a^b indica che a usa il modulo b) ** Flusso dei dati, tramite frecce possibile indicare quale modulo sfrutta quale risorsa (Esempio: a ! b indica che il modulo a legge dalla risorsa b, a $ b il modulo a legge dalla e scrive sulla risorsa b). * Coesione, per coesione di un componente si intende un modulo che realizza una o funzioni simili (Esempio: modulo di visualizzazione delle immagini) e quindi, in caso di errore (esempio visualizzata male) possibile identificare velocemente il modulo incriminato . Quindi gli elementi nel modulo non devono esserci per pura coincidenza ma in seguito ad uno studio accurato, in modo da includere procedure (e i relativi dati) coerenti ad un unico tema applicativo. Ci sono diversi gradi di coesione: Modificata la linea 80: da:
** Temporal, il criterio di appartenenza a:
** Temporal, il criterio di appartenenza legato al tempo (es. funzioni di inizializzazione) Modificata la linea 82: da:
** Sequential, di un elemento a:
** Sequential, di un elemento del successivo Modificate le linee 85-86: da:
* (Dis)accoppiamento, si ha un accoppiamento, tra moduli quando sono interconnessi per scambiarsi dati. Bisogna ridurre al minimo il grado di interconnessione tra moduli evitando il caso in cui tutto vede tutto e un modulo modificare i dati di un altro modulo. In caso di modifiche sarebbe veramente catastrofico doverci rimettere le mani. Il caso migliore a:
* (Dis)accoppiamento, si ha un accoppiamento, tra moduli quando sono interconnessi per scambiarsi dati. Bisogna ridurre al minimo il grado di interconnessione tra moduli evitando il caso in cui tutto vede tutto e un modulo modificare i dati di un altro modulo. In caso di modifiche sarebbe veramente catastrofico doverci rimettere le mani. Il caso migliore quello in cui un modulo, che deve comunicare con modulo, gli passa una lista di parametri sulla quale lavorare. Modificata la linea 99: da:
* , a:
* , sempre una parte critica che richiede maggiore attenzione Modificata la linea 103: da:
Il processo di progettazione, in generale, a:
Il processo di progettazione, in generale, composto da tre fasi. Nella prima si definisce il progetto concettuale, nella seconda si attua la sintesi del sistema costruibile, nella terza, la fase di analisi, si attuano verifiche di progetto Modificata la linea 120: da:
Nella il processo di analisi e quello di sintesi sono interconnessi e non a:
Nella il processo di analisi e quello di sintesi sono interconnessi e non distinguibile concretamente quando si in una fase o . di analizzare tutto e poi sintetizzare una soluzione molto astratta Modificate le linee 127-129: da:
* generale dei requisiti * Il dettaglio non Tra queste due fasi viene a definirisi una fase di interleaving a:
* generale dei requisiti fermata ad un definito livello considerato sufficiente per stipulare un contratto * Il dettaglio non applicato egualmente a tutti i componenti ( dei componenti, tempi di consegna, componenti esistenti) Tra queste due fasi viene a definirisi una fase di interleaving una Modificata la linea 135: da:
e il progetto. La caratteristica di questi modelli a:
e il progetto. La caratteristica di questi modelli che possono simulare Modificata la linea 147: da:
corrispondere livelli di dettaglio diversi, a:
corrispondere livelli di dettaglio diversi, a seconda delle competenze Modificata la linea 159: da:
requisiti) un codice componente del progetto in cui a:
requisiti) un codice componente del progetto in cui stato implementato. Modificata la linea 163: da:
avere una base grafica la comunicazione visiva a:
avere una base grafica la comunicazione visiva chiara e diretta. Modificata la linea 167: da:
bisogno di tecniche diverse). Si cosa a:
bisogno di tecniche diverse). Si cosa possibile modellare e con quale Modificata la linea 170: da:
Il nucleo del progetto a:
Il nucleo del progetto il modello dei dati, attorno al quale vengono create Modificata la linea 178: da:
Questa tecnica a:
Questa tecnica utilizzata quando dobbiamo gestire dei processi che producono Modificata la linea 189: da:
Il progetto a:
Il progetto interamente basato sugli oggetti. Sono delle che racchiudono Modificata la linea 191: da:
tecnica di modellazione utilizzata a:
tecnica di modellazione utilizzata il diagramma delle classi, in linguaggio Modificate le linee 200-201: da:
tecniche, richiede di sapere anche dove questi oggetti finiranno, sapere qual a:
tecniche, richiede di sapere anche dove questi oggetti finiranno, sapere qual il componente fisico per cui sono destinati. I vincoli da applicare a Modificate le linee 244-245: da:
Il progetto architetturale prodotto. del software a:
Il progetto architetturale quella fase in cui si gioca la interna del prodotto. del software sempre orientata verso la creazione Modificata la linea 257: da:
questo aspetto diventa facile. Infine a:
questo aspetto diventa facile. Infine la fase di analisi, da effettuare Modificata la linea 260: da:
la del riuso a:
la del riuso possibile identificare progetti diversi che Modificata la linea 263: da:
Inoltre garantisce la sua in quanto a:
Inoltre garantisce la sua in quanto stata provata nel progetto Modificata la linea 281: da:
Per documentare a:
Per documentare utile: Modificata la linea 292: da:
stessa forma e stile, a:
stessa forma e stile, lo stesso pattern architetturale. Modificata la linea 297: da:
questa struttura prevede che al layer superiore a:
questa struttura prevede che al layer superiore permesso di usare il layer Modificate le linee 301-302: da:
sottostante, applicando questo concetto pila. Ogni layer collezione di software, a:
sottostante, applicando questo concetto pila. Ogni layer una collezione di software, delle procedure, oggetti, strutture dati, ecc. Modificata la linea 312: da:
* Costruzione incrementale, a:
* Costruzione incrementale, inserire nuovi strati sovrastanti a seconda delle esigenze (come del protocollo HTTP) Modificata la linea 321: da:
trasformazione a:
trasformazione indipendente dal lavoro che altri filtri stanno svolgendo, sia Modificata la linea 323: da:
dei dati in ingresso non a:
dei dati in ingresso non ancora stato consumato del tutto. Le connessioni Modificata la linea 325: da:
a:
indipendente che non condivide lo stato con altri filtri. Modificata la linea 327: da:
* Il comportamento globale a:
* Il comportamento globale dato dal comportamento locale dei singoli filtri. Modificata la linea 332: da:
* Pipeline: lavora di continuo, a:
* Pipeline: lavora di continuo, garantire un flusso di dati sufficiente. I filtri possono lavorare in parallelo preoccupandosi solamente di trasformare gli ingressi in uscite. Modificate le linee 339-340: da:
della struttura di controllo struttura centrale a:
della struttura di controllo data dal componente centrale. Lo stato della struttura centrale la fonte principale del controllo. Il cambio di stato attiva Modificata la linea 361: da:
tutti i processi e le chiamate tra processi. Per esempio si potrebbe avere delle risorse condivise tra processi che accedono ad un unico software gestore risorse. Un processo in wait per accedere a una risorsa se non a:
tutti i processi e le chiamate tra processi. Per esempio si potrebbe avere delle risorse condivise tra processi che accedono ad un unico software gestore risorse. Un processo in wait per accedere a una risorsa se non subito disponibile. Modificata la linea 366: da:
invoca direttamente i sottosistemi interessati. Quindi non a:
invoca direttamente i sottosistemi interessati. Quindi non direttamente Modificata la linea 370: da:
Ogni interrupt a:
Ogni interrupt associato a un indirizzo e ad un handler, una commutazione Modificata la linea 375: da:
ogni nuovo sistema moderno a:
ogni nuovo sistema moderno distribuito. Modificata la linea 378: da:
* Architetture di oggetti distribuiti, non a:
* Architetture di oggetti distribuiti, non distinzione tra client e server. Modificate le linee 403-404: da:
server. La rete server, mentre non a:
server. La rete utilizzata per connetterli tra loro. I client conoscono i server, mentre non richiesto che i server conoscano i client. Server e client Modificata la linea 406: da:
a:
divisa in tre strati: Modificata la linea 417: da:
Non a:
Non distinzione tra clienti e serventi, ogni oggetto distribuito sulla rete Modificata la linea 438: da:
in contesti diversi. Un design pattern a:
in contesti diversi. Un design pattern una regola tripartita, che esprime Modificata la linea 446: da:
prodotto a:
prodotto utilizzabile da clienti. Modificata la linea 448: da:
Il framework a:
Il framework una struttura software sulla quale vengono innestati componenti Modificata la linea 456: da:
Un componente a:
Un componente software caratterizzata da: Modificata la linea 472: da:
se avviene tramite un middleware esistente a:
se avviene tramite un middleware esistente detta a grana fine in quanto si ha una Modificata la linea 475: da:
Compito della verifica del progetto a:
Compito della verifica del progetto quello di controllare che il progetto Modificata la linea 509: da:
La verifica di un prodotto non a:
La verifica di un prodotto non effettuabile direttamente sul codice in Aggiunte le linee 1-530:
! Progettazione '''Autori:''' [[Profiles.Alberto|Alberto Taiocchi]]\\ ->'''Sommario''' !! Introduzione creare un modello del software che implementi correttamente tutti i requisiti del cliente e risulti di facile lettura e comprensione per i programmatori. Gli ingegneri del software devono esaminare varie alternative di progettazione e convergere su una soluzione adatta al progetto. !! Criteri generali !!! Ruolo della progettazione La progettazione specifica la struttura ed il funzionamento di un software che soddisfi le specifiche (funzionali e non funzionali), costruibile con le risorse assegnate (vincoli di costo, tempo e personale). I compiti e le esigenze della progettazione comprendono: * Soddisfacimento delle specifiche funzionali e non funzionali * Rispetto dei vincoli (Personale, tempo, costi) conoscenze, problemi, vincoli, risorse per generare una soluzione. La soluzione limiti. !!! Documento di progettazione * Come le funzioni sono allocate a componenti software. * Come i componenti interagiscono tra di loro. come dovrebbe, si possono trovare disegni orientativi e non dettagliati, architetture e dettagli mischiati. Il documento non contiene informazioni che poi verranno implementate. Ci sono anche casi nei quali il documento non due tipi di documenti: * Documento di progettazione (progetto), i disegni che usa il progettista per capire e spiegare ai suo programmatori che cosa devono fare. !!! Progettazione architetturale e di dettaglio esecutivo Dopo la fase di specifica dei requisiti (e il rilascio del documento di specifica), la fase di progettazione viene divisa in due parti sequenziali: ''progettazione architetturale'' e ''progettazione di dettaglio''. una rete intranet, oppure per un database sono indicate solamente le operazioni di input/output, senza specificare il DBMS usato). software (struttura statica, dinamica e implementazione). Nella fase terminale si specificheranno in dettaglio i componenti software che realizzeranno il sistema. !!! Viste relativamente indipendenti. Le viste possono essere classificate in base alla struttura. * ''Architettura software'', con questa vista si rappresentano i moduli software e le loro interconnesioni. Si divide in struttura statica nella quale si rappresentnao i moduli e programmi che compongono il sistema e in struttura dinamica nella quale si gestiscono i flussi di dati tra i moduli software. Solo in questa fase si indicano le risorse che vengono scambiate e in che modo. !!! Regole e principi di progettazione Un buon ingegnere del software per realizzare un prodotto si basa su regole e principi di progettazione. Tra le fondamentali vengono ricordate quelle di: * ''Interazioni tra moduli'' ** Coincidental, gli elementi di un modulo sono nel modulo per pura coincidenza ** Logical, esiste un criterio debole di appartenenza (es. Funzioni che trattano calcoli matematici. Molte funzioni legate in modo complesso potenzialmente separabili in moduli diversi) ** Communication, gli elementi hanno lo stesso insieme di dati di ingresso e/o uscita (es. gestione di un file) ** Informational, il modulo contiene tutte le procedure ed relativi dati connessi ad uno specifico tema applicativo I gradi di accopiamento si dividono in base al come: ** Content, un modulo modifica dati e istruzioni interni ad un altro modulo ** Common, due moduli sono legati da una struttura di dati globale ** Control, un modulo passa flag di controllo ad un altro modulo (altera il flusso di controllo) ** Stamp, come common ma con aree suddivise per gruppi di moduli ** Data, un modulo passa una lista di parametri ad un altro modulo ** Massimo numero di interconnessioni per modulo, Numero medio di interconnessioni per modulo ** Morfologia, in un albero ogni nodo deve essere raggiunto con un cammino minimo. !!! Euristiche Sono regole generali utili per evitare di progettare sistemi poco elastici: !! Processi di progettazione (strategie) !!! Forme, strutture e decorazioni qualitative e costruttive. Come in campo edile, quando si progetta un edificio, anche nella progettazione software si genera una forma (il grattacielo) in grado di risolvere il problema in questione, soddisfando i requisiti funzionali e non funzionali. Una volta definita la forma si crea la struttura, lo scheletro che sostiene la forma (fondamenta, muri portanti,..) ed infine si aggiungono i dettagli. Ci sono vari modi per attuare la sintesi di un sistema: I processi non sono mutuamente esclusivi, dipendono da caratteristiche tecniche, dalla definizione dei requisiti, da altri fattori come tempo e costi. di progettazione. !!! Analisi dei requisiti e sintesi del sistema, integrazione con la specifica dovuta principalmente a motivazioni tecniche: * Specifica vincolata da decisioni di progettazione convivenza quasi sequenziale tra requisiti e specifica e progetto. In un sistema semplice si passa dai requisiti e specifica al progetto mentre di norma si ripetono ciclicamente questi due passaggi. !!! Modelli operazionali e trasformazioni I modelli operazionali definiscono il modo di gestire le relazioni tra la specifica i comportamenti reali, il comportamento del modello del sistema viene iterativamente verificato e modificato fino a diventare completo e costruibile. identifica i componenti e li descrive a grandi linee, in particolare si concentra sulla loro connessione. progetta ogni singolo componente e le interfacce di connessione tra loro. Il livello di dettaglio del progetto esecutivo di dettaglio deve essere tale da essere considerato dai programmatori un documento di specifica completo che deve solo essere trasformato in codice. In situazioni diverse possono tecniche dei programmatori, le loro conoscenze del settore applicativo, se si programma in casa o in subappalto. il lavoro svolto da ciascun programmatore, in modo da mantenere un filo il rapporto, la traccia, del lavoro svolto fino a quel momento. Inoltre permette di identificare in modo univoco i componenti del sistema e quali requisiti hanno implementato. al codice del requisito (che era stato assegnato durante la fase di analisi dei !! Linguaggi e metodi di progettazione Per modellare il progetto si hanno a disposizione diversi linguaggi, ognuno dotato di regole e guide da seguire. In comune hanno la caratteristica di Ognuna di queste tecniche ha delle caratteristiche fondamentali che la (un database e un protocollo, essendo concettualmente diversi, avranno tecnica. !!! Dati il resto delle funzioni. Le fasi principali sono: * Progettazione concettuale (lo schema ER) * Progettazione logica (conversione da ER in forma di tabelle) * Progettazione fisica (implementazione) !!! Funzioni ingressi ed uscite. Vengono rappresentati con una evoluzione dei diagrammi di flusso, i diagrammi di struttura, e rappresentano in modo semplice e intuitivo come le funzioni dei vari processi si scambiano dati durante il loro funzionamento. Si utilizzano i seguenti schemi grafici: * Quadrato per rappresentare gli attori del sistema * Rettangolo con i bordi smussati per processi e funzioni * Rettangolo per le basi di dati * Frecce per evidenziare il flusso dei dati !!! Oggetti al loro interno dati e funzioni di elaborazione dei dati stessi. La risulta di difficile lettura da parte del cliente. Per definirne il comportamento si utilizzano diverse tecniche, alcune delle quali fanno parte della grande famiglia di linguaggi UML: * Automi a stati finiti * Diagramma di sequenza questa tecnica sono quelli della programmazione ad oggetti (Object Constrain Language). !!! Eventi Questa tecnica prevede di pilotare gli eventi che guidano lo stato del sistema, utilizzando gli automi a stati finiti. Sono composti da: * Stati, che rappresentano la situazione globale del sistema. * Eventi, particolari situazioni da gestire che possono portare a diverse configurazioni di stati. * Azioni !!! Concorrenza Si utilizza questa tecnica quando si devono modellare processi concorrenti e in generale sistemi distribuiti o basati sulla concorrenza. La tecnica di modellazione utilizzata sono le reti di Petri. !!! Tempo che evolvono in tempo reale, ma sistemi caratterizzati da vincoli di tempo (di varia natura e di vari ordini di grandezza) che devono essere rispettati si intendono tempi di risposta accettabili per sistemi interattivi, risposta a seconda del dominio applicativo in cui si sta lavorando (Esempio: i tempi di risposta di un pilota automatico devono essere molto brevi, per ovvie ragioni di sicurezza). Le tecniche di modellazione utilizzate sono degli adattamenti * Diagrammi di flusso arricchiti con flussi di controllo. * Automi a stati finiti arricchiti per tener conto della durata delle transazioni. * Reti di petri temporizzate. !!! Interazione uomo macchina raggiungere una certa funzione, ect. !!! Integrazione dei linguaggi Quindi bisogna saper modellare tutti gli aspetti (in una applicazione presentazione dei dati e di interrogazione). !! Architetture e pattern di progettazione dati. !!! Architetture importante. Il progetto architetturale deve essere in grado di definire un nella fase di analisi dei requisiti e sintetizzati nel documento di specifica). team. Infatti la scomposizione in moduli di un problema grosso permette di della comunicazione tra il personale coinvolto. Scomponendo il lavoro anche conoscenza acquisita durante il lavoro precedente, riducendo tempi e costi. precedente. Il tutto porta a tenere una traccia, un documento che descrive tutto il lavoro svolto. Deve essere leggibile da tutto lo staff che ci lavora e ordinati, con strumenti di modellazione adeguati. !!!! Rappresentazione Si utilizzano scatole per rappresentare i componenti e righe per evidenziare le connessioni tra i componenti. Utilizzando questi elementi base possiamo rappresentare la: * Struttura statica * Struttura dinamica * Struttura del codice. dei processi, del codice di implementazione, una vista dei componenti fisici del sistema e di uno scenario che racchiude il tutto. !!!! Documentazione * Avere uno schema architetturale preesistente, in cui si seguono i passi impostati * Utilizzare gli strumenti linguistici studiati. !!! Pattern architetturali Uno stile architetturale definisce una famiglia di sistemi software che hanno in comune uno schema ricorrente che si ripete. Conoscere gli stili permette possono avere funzioni diverse e domini applicativi differenti, ma avere la In elenco sono descritti alcuni pattern architetturali. !!!! Layers Si ha una serie di componenti, o layer (disegnati con delle scatole) connessi tra loro (da delle frecce), realizzando una forma tipo pila. La semantica di inferiore, ma non viceversa. Questa logica permette di semplificare la struttura evitando cos`ı di generare studi intricati e difficilmente gestibili. Quindi la correttezza del layer sovrastante dipende dalla correttezza del layer I servizi del layer sono accessibili esclusivamente attraverso delle interfacce complessa, il layer sovrastante. I vantaggi offerti da questa struttura sono: * Ci possono essere, senza conseguenze, cambiamenti locali per ogni layer, senza modificare le interfacce di connessione Le possibili varianti sono: * Segmented Layer * Bridge !!!! Pipes and filter I componenti di questa struttura (scatole) vengono chiamati filtri. Leggono un flusso di dati in ingresso e producono un flusso di dati in uscita. Questa a monte sia a valle. Il flusso dei dati in uscita inizia quindi quando il flusso I filtri non sono adatti a gestire applicazioni interattive, rappresentano solo un flusso di informazioni. Le possibili varianti sono: !!!! Repository In questa struttura si ha una serie di componenti satellite (scatole) indipendenti dati centrale (un database). Le connessioni tra la risorsa di dati centrale e i componenti satellite sono un flusso di dati bidirezionale. La fonte principale gli altri componenti !!! Stili di controllo Rappresentano gli schemi di gestione del flusso di controllo tra componenti (le scatole). * A controllo centralizzato: ** Call Return ** Manager * A controllo basato su eventi: ** Selective Broadcast ** Interrupt Driver Esistono altri stili classificabili per tipologia applicativa (acquisizione in frequenza, eventi sismici, ect.). !!!!! Call Return Si sceglie questo stile quando: * Si devono integrare prodotti software in cui si possono solo aggiungere delle interfacce !!!!! Manager !!!!! Selective Broadcast il gestore a controllare i sottosistemi, ma sono loro stessi a richiedere un !!!!! Interrupt Driven !!! Architetture di sistemi distribuiti su elaboratori diversi ed autonomi connessi da una rete. Generalmente !!!! Architetture distribuite * Architetture client/server. Ogni oggetto distribuito collabora con altri oggetti, fornendo e richiedendo servizi. !!!! Vantaggi delle architetture distribuite: * Condivisione delle risorse (distribuire dati con sistemi raid di harddisk). * Trasparenza delle applicazioni, esecuzione operazioni senza preoccuparsi, per esempio, su quale server si trovano i dati. !!!! Svantaggi delle architetture distribuite.: * Sicurezza, controllo degli accessi e privacy (intesa come security) difficile da gestire. !!!! Middleware Nelle architetture dei sistemi distribuiti si utilizza uno strato di software su prodotti standard di mercato. I servizi di comunicazione di base si basano sui socket. Middleware tradizionali sono RPC, RDA, MOM, OSF; mentre quelli ad oggetti sono CORBA, RMI, DCOM. !!!! Architettura client-server Le elaborazioni e i dati sono distribuiti su un insieme di componenti. Un insieme di componenti server fornisce servizi (gestione dei dati, stampa, processi di elaborazione), mentre un altro insieme chiede servizi ai componenti sono processi logici che possono essere mappati su processori fisici diversi. * Presentazione, che si occupa delle interazioni uomo macchina * Gestione dei dati, per dialogare con le banche dati A seconda di dove questi strati vengono fisicamente implementati si possono avere due tipi di architettura client/server: two tier (con thin o fat o direttamente nel client) e three tier (dove i tre strati sono su computer diversi). !!!! Architetture ad oggetti distribuiti fornisce-richiede servizi a-da altri oggetti distribuiti.La comunicazione tra oggetti avviene attraverso uno strato di middelware chiamato Object Request Broker (bus software). Questo bus software gestisce le richieste di servizi. Conosce tutti gli che eseguono sullo stesso elaboratore. Ogni elaboratore di un sistema distribuito ha un ORB e gli ORB comunicano tra loro per gestire gli oggetti distribuiti. CORBA (Common Object Request Broker Architecture) definito dallo standard internazionale (OMG - Object Management Group), tramite il mappato con diversi linguaggi (C++, Java). !!! Pattern di componenti Descrivono un problema ricorrente in un dato dominio, e la sua soluzione, in modo tale che possa essere riutilizzata, anche se in modo diverso una relazione tra un contesto, un problema ed una soluzione. !!! Sviluppo di famiglie di componenti Sviluppare una famiglia di prodotti porta a realizzare una struttura base da Nel progetto di famiglie di prodotti si ha la convergenza di diversi aspetti, tra cui le esigenze specifiche del cliente, gli aspetti comuni delle classi di applicazione e vantaggi gestionali (come la riduzione del costo) in quanto il !!! Sviluppo di framework aggiuntivi o adattamenti, che permettono di realizzare una specifica applicazione appartenente ad una famiglia di applicazioni. Incorpora un insieme di conoscenze di base del dominio applicativo di interesse. !!! Sviluppo attraverso integrazione di componenti Lo sviluppo attraverso integrazione di componenti comporta lo spostamento * esistenza in modo indipendente * interfaccia definita ed un definito contesto di utilizzo * avere un contesto di cui interessarsi ed inserirsi * rende disponibile un insieme complesso di funzioni applicative di base * viene integrato in un processo. Le tecniche di integrazione utilizzate sono il bridge e il wrapping. !!!!! Bridge componente da integrare. !!!!! Wrapping Un oggetto software incapsula il componente da integrare rendendone disponibili i servizi come se appartenessero al nuovo sistema nativamente. ed applicazioni, anche eterogenei come database, programmi applicativi o sola invocazione di metodi e oggetti. !! Verifica di progetto rispecchi il documento di specifica e che le specifiche funzionali e non funzionali termine la fase di verifica occorre possedere il documento dei requisiti (la specifica) e il documento di progetto (il progetto). specifica e delle verifiche sul progetto. Per ogni classe di requisiti si devono controllare criteri relativi a: * Efficienza Quindi nella specifica devono essere presenti questi aspetti che verranno verificati sulla pelle del progetto. Le verifiche possono essere fatte da una persona estranea al progetto. !!! Livelli di verifica Le verifiche possono essere utilmente strutturate per livelli. . . * Livelli del costo di verifica problema. ** Sviluppo di un prototipo e prove di prestazioni. Si ha una verifica quantitativa precisa. ** Analisi ulteriori. !!! Scenari Possono essere utilizzati dai requisiti o costruiti specifici scenari per verificare le caratteristiche del progetto: * Privatezza, scenari di possibili attacchi di hacker o usi non autorizzati. !!! Tipi di verifiche quanto non esiste ancora. Si utilizzano diversi tipi di verifiche tra cui: * Ispezione * Analisi * Animazione e simulazione !!!!! Ispezioni inoltre che tutti i requisiti funzionali siano allocati e soddisfatti. !!!!! Analisi Si devono effettuare dei ragionamenti sul progetto: * Comprendere il requisito * Esaminare il progetto * Studiare le caratteristiche del progetto rispetto al requisito e verificarne il comportamento basandosi sul modello * Definire gli scenari appropriati e valutare il comportamento del progetto * Esaminare i casi limite * Valutare le alternative di progettazione !!!!! Animazione e simulazione Si effettuano delle simulazioni del funzionamento del prodotto creando dei prototipi. Es. si analizza il funzionamento del sistema usando le reti di Petri. |