Processo di sviluppo software unificato. Processo di sviluppo unificato e programmazione estrema

In conformità con GOST 34.601-90 “AS. Fasi di creazione" stabilisce le seguenti fasi di creazione di un AIS, che a loro volta possono essere suddivise in fasi:

· formazione dei requisiti per l'AIS;

· sviluppo del concetto AIS;

· compito tecnico;

· progetto preliminare;

· progetto tecnico;

· documentazione di lavoro;

· la messa in produzione.

Ogni fase ha il proprio set di documentazione di progettazione e implementazione dei moduli tecnici e software del sistema. La pratica dimostra che il processo di creazione di un sistema è iterativo e incrementale. Gli autori di UML lo sottolineano nel definire il concetto processo unificato di sviluppo di software e informazioni. Sebbene nella prima fase venga formato un insieme di requisiti per l'AS nel suo insieme, in realtà all'inizio è sempre incompleto e viene chiarito nelle fasi successive. devo fare iterazioni, cioè ripetere singoli passaggi e fasi, in tutto o in parte. Inoltre, un sistema reale è multifunzionale e complesso, quindi è solitamente suddiviso in sottosistemi e insiemi separati di compiti, distinguendo sottosistemi e compiti del primo stadio, del secondo, ecc. Il sistema è in fase di creazione in modo incrementale, attraverso graduali incrementi di funzionalità con la sostituzione delle soluzioni progettuali preliminari con soluzioni più sviluppate e maggiormente rispondenti alle esigenze dell'utenza. Ciò riduce i rischi finanziari e fa risparmiare tempo e consumo di risorse nelle fasi finali della creazione.

Quando si utilizza la metodologia UML per creare software AIS e supporto informativo, si propone di costruire una serie di modelli interconnessi che riflettano le proprietà statiche e dinamiche del sistema futuro:

· modello di caso d'uso;

· modello di analisi;

· modello di progettazione;

· modello di distribuzione;

· modello di attuazione;

· modello di prova.

Modello di caso d'uso include diagrammi dei casi d'uso e scenari corrispondenti, descrive i requisiti funzionali del sistema e il suo comportamento durante l'interazione con gli utenti.

Modello di analisi include diagrammi di classi generici per l'implementazione di casi d'uso a livello logico, diagrammi di sequenza associati e/o diagrammi di collaborazione ed è uno schizzo di come verranno implementati i casi d'uso a livello logico.

Modello di progettazioneè una rappresentazione dettagliata dell'implementazione fisica del modello di analisi e comprende diagrammi di pacchetto (sottosistema), diagrammi di classe dettagliati, diagrammi di sequenza e/o diagrammi di cooperazione, diagrammi di stato, diagrammi di attività con vari gradi di dettaglio.

Modello di distribuzione include diagrammi di distribuzione preliminari che definiscono tutte le configurazioni di rete su cui può essere eseguito il sistema. I diagrammi di distribuzione indicano i nodi di rete, i tipi di connessione e la distribuzione delle classi di sistema attive tra i nodi.

Modello di implementazione descrive come le classi di progettazione vengono implementate come componenti. Di conseguenza, include diagrammi dei componenti, tracce di classi (implementazione), diagrammi di distribuzione dettagliati e una descrizione dell'architettura del sistema.

Modello di prova contiene una serie di casi di test, procedure di test e descrizioni dei componenti di test. Specifica i metodi per testare i componenti di sistema eseguibili.

Confrontiamo i processi di costruzione dei modelli con le fasi standardizzate di creazione di un AS. Il modello del caso d'uso è costruito nella fase di formazione dei requisiti per l'AS; il modello di analisi è nella fase di sviluppo del concetto di AS. Nella fase delle specifiche tecniche e della progettazione preliminare, viene costruito un modello di progettazione. Viene perfezionato nella fase di progettazione tecnica e integrato da un modello di implementazione. Nella fase di documentazione di lavoro vengono creati modelli di implementazione e test. Nella fase di commissioning, infine, il modello di testing viene affinato e diventa un modello di riferimento durante il funzionamento, destinato alle verifiche periodiche del corretto funzionamento e alla diagnostica del sistema.

1.5 Componenti del linguaggio UML

Linguaggio di modellazione unificato UML(Unified Modeling Language) è un linguaggio di modellazione visiva utilizzato per specificare, visualizzare, configurare e documentare sistemi complessi (incluso il software) utilizzando la tecnologia orientata agli oggetti.

Quando si crea un AS nella metodologia UML, vengono utilizzati i principi dell'analisi del sistema strutturale noti dalle metodologie Hein/Sarson e SADT:

· sviluppo graduale dall'alto verso il basso;

· tecnica dei diagrammi;

· gerarchia delle descrizioni;

· rigorosa formalizzazione della descrizione delle soluzioni progettuali;

· sviluppo iniziale del progetto a livello logico senza dettagli di attuazione tecnica;

· modellazione concettuale in termini di area tematica affinché il cliente comprenda la progettazione del sistema;

· supporto tecnologico con strumenti (sistemi CASE).

È possibile studiare un modello di un sistema complesso in UML per ottenere caratteristiche stimate dell'efficienza dei processi nel sistema.

I modelli per l'implementazione, l'implementazione e il test del software AS e il supporto delle informazioni in UML possono essere utilizzati come progetto applicativo con successiva generazione automatizzata del codice applicativo in uno degli ambienti di programmazione selezionati.

Un modello abbastanza completo di un sistema complesso dovrebbe riflettere due aspetti:

-statico(strutturale) – composizione, struttura dei componenti e loro relazioni;

-dinamico(comportamentale) – descrizione della logica dei processi che si verificano nel sistema o da implementare.

Il metodo principale di rappresentazione dei modelli adottato in UML sono i diagrammi dotati di informazioni testuali, comprese le espressioni nel linguaggio di vincolo integrato OCL, nonché nei linguaggi di programmazione e di interrogazione delle informazioni utilizzati per implementare il sistema.

Il principio di base della modellazione: un sistema è modellato come un gruppo di oggetti discreti che interagiscono tra loro in modo tale da soddisfare le esigenze dell'utente.

Un modello statico specifica la struttura, i tipi di oggetti e le relazioni tra gli oggetti. Il modello dinamico determina il comportamento degli oggetti nel tempo (la storia degli oggetti) e la loro interazione.

Fondamentalmente, UML è un linguaggio di modellazione discreto, ovvero contiene il concetto di eventi discreti e cambiamenti di stato. I processi continui sono modellati approssimativamente mediante discretizzazione.

Il modello ha due aspetti: informazione semantica (semantica) e rappresentazione visiva (notazione).

La composizione completa delle rappresentazioni del modello nel linguaggio UML è riportata nella Tabella 1

Tabella 1 – Rappresentazione dei modelli di sistema in UML.

Il modello concettuale più comune di un sistema è il diagramma dei casi d'uso; è il punto di partenza per costruire altri diagrammi.

Tutti i diagrammi linguistici sono grafici di tipo speciale, contenenti vertici (figure geometriche) collegati da bordi (archi). Di solito la scala dell'immagine e la posizione dei vertici non sono particolarmente importanti, tuttavia nel diagramma di sequenza viene introdotto l'asse temporale e lì è significativo.

Le connessioni sono indicate da varie linee sul piano, il testo è scritto all'interno delle figure e alcuni simboli grafici possono essere raffigurati vicino ai vertici e alle connessioni. Le estensioni UML consentono diagrammi spaziali.

Il linguaggio ha 4 tipi di strutture grafiche:

· icone (pittogrammi);

· simboli grafici su un piano;

· percorsi (linee);

· righe di testo.

1.6 Livello concettuale. Modello di caso d'uso

In generale, il processo di progettazione orientata agli oggetti avviene secondo i principi base dell’analisi dei sistemi strutturali: progettazione top-down con la costruzione di una gerarchia di diagrammi che ci spostano gradualmente da un livello all’altro: concettuale – logico – fisico (implementazione)

Il diagramma di primo livello è considerato quello proposto da A. Jacobson in OOSE diagramma dei casi d'uso sistemi nel loro complesso. È questa la rappresentazione concettuale iniziale del sistema ed è costruita con l'obiettivo di:

· determinare i confini generali e il contesto dell'area tematica modellata;

· formulare requisiti generali per il comportamento funzionale e l'interfaccia del sistema;

· preparare la documentazione iniziale per l'interazione tra sviluppatori e clienti - utenti del sistema.

Il punto di vista del modello: utente esterno del sistema. Un diagramma dei casi d'uso include attori, casi d'uso e associazioni.

Attante(attore, entità esterna, attore) - una descrizione astratta di una classe di sorgenti/ricevitori di messaggi che interagiscono direttamente con un sistema, sottosistema o classe. Questa è la descrizione ruoli giocato dall'utente (persona o altro sistema, sottosistema, classe) durante l'interazione con il sistema. Essenzialmente, si tratta di una generalizzazione di richieste di informazioni simili al sistema che ne richiedono una certa servizio(Servizi).

Un attante non deve necessariamente essere identificato con un individuo o un dispositivo specifico, sebbene ciò sia talvolta possibile in linea di principio se svolgono solo un ruolo. Molto spesso, fisicamente, si tratta di persone e dispositivi diversi che accedono al sistema per ricevere lo stesso servizio. Al livello più alto, ad esempio, gli attanti possono essere un operatore, un amministratore di sistema, un amministratore di database, un utente normale o qualche classe di dispositivi.

Tutti i possibili attanti esauriscono tutte le possibili modalità di interazione dell'utente con il sistema (sottosistema, classe). Quando si implementa un sistema, gli attanti sono incarnati in persone e oggetti fisici. Una persona o un oggetto fisico, a seconda della modalità di interazione, possono rappresentare più attanti (ruoli diversi). Ad esempio, la stessa persona può essere un operatore e un amministratore del database, un venditore e un acquirente, ecc.

In molti AS non ci sono altri attanti eccetto le persone. Tuttavia, gli attanti possono essere un sistema esterno, un dispositivo I/O o un timer (comunemente presente nei sistemi in tempo reale integrati). Tra gli attanti del caso d’uso ce n’è uno che spicca attante principale(attore primario), che avvia il lavoro con il sistema. Il resto è secondario, partecipa anche al caso d'uso, ricevendo risultati e inserendo alcuni dati intermedi.

A livello logico e fisico, gli attanti sono rappresentati da classi e oggetti che sono istanze di classi. È possibile costruire una gerarchia di attanti con ereditarietà di tutti i ruoli e relazioni, attributi e operazioni che ha l'attante antenato. Un'istanza di un attante figlio può sempre essere utilizzata nel luogo del sistema in cui è dichiarato l'uso dell'attante antenato (principio di sostituzione).

Un attante può essere rappresentato sui diagrammi in due modi:

3. Simbolo di classe (rettangolo) con indicazione interna dello stereotipo

4. Più standard: "uomo" con un'iscrizione (simbolo di una persona)

L'attante è esterno al sistema e la sua struttura interna non è determinata. È la fonte/destinatario dei messaggi.

Cliente

Caso d'uso(precedente, caso d'uso) – una descrizione astratta della classe di servizio (funzioni di servizio) fornita all'attante in risposta alle sue richieste.

Il servizio può essere fornito dal sistema nel suo complesso, da un sottosistema o da una classe. Pertanto, un caso d'uso significa modellare alcune parti della funzionalità o del comportamento di un sistema. Un caso d'uso ha un nome e significa una certa sequenza di azioni visibili a una fonte/destinatario esterno (attante). Il modo interno di implementare l'opzione è nascosto e rivelato a livelli di dettaglio inferiori. diagramma di cooperazione. Come ogni classe, un caso d'uso ha attributi e operazioni, la cui implementazione è esposta a livello fisico.

Il caso d'uso comprende l'intera sequenza di messaggi che l'attante inizia e termina con il sistema (sottosistema, classe). Pertanto, qualsiasi istanza di implementazione di un caso d'uso ha sempre un inizio nel tempo e una fine quando nessun attante invia messaggi per questa opzione. Ciò include anche messaggi di errore, opzioni per eseguire la funzione di manutenzione con diverse impostazioni (alternative).

Un'istanza di un caso d'uso è l'esecuzione di un caso d'uso che inizia dopo aver ricevuto un messaggio da un'istanza dell'attante. In risposta a un dato messaggio, il caso d'uso esegue una sequenza specifica di azioni, come l'invio di un messaggio ad altre istanze dell'attante (non solo all'originatore). A loro volta, questi attanti inviano messaggi a questa istanza del caso d'uso e l'interazione continua finché non vengono più ricevuti messaggi di questo tipo. Questo segna la fine del caso d'uso.

Viene mostrata la relazione tra l'attante e il caso d'uso associazione.

Il diagramma descrive il caso d'uso in due modi:

1) un'ellisse, al suo interno viene inserito un nome

2) un rettangolo, come qualsiasi classe

Cliente

Sensore

Tra attanti e casi d’uso l’associazione è l’unico tipo di connessione. Inoltre, ha una semantica commutazione della comunicazione, ovvero lo scambio di messaggi, quindi di solito non viene contrassegnato poiché il contesto è chiaro dall'attante e dalla notazione dei casi d'uso. Ma puoi contrassegnarlo e indicare anche la molteplicità della connessione:

Cliente della banca

Molteplicità(molteplicità) caratterizza il numero di istanze specifiche di una classe che partecipa a una determinata connessione (un cliente può emettere un numero illimitato di prestiti).

Generalmente associazioneè una relazione tra due o più componenti del modello. Poiché nella maggior parte dei casi i componenti sono alcune classi di oggetti, un'istanza di associazione è semplicemente una lista ordinata di riferimenti a istanze specifiche, magari dotata di attributi di associazione (proprietà).

Il nome dell'associazione, se presente, deve essere univoco. Si forma secondo il significato dei rapporti tra le classi partecipanti all'associazione. Ad esempio, "Dipendente lavora dentro Direttore del dipartimento completa informatico”, ecc.

Le associazioni sono esse stesse classi ( classe associativa, classe di associazione), ha sia proprietà di classe che di associazione. Le istanze di questa classe sono connessioni che non hanno solo collegamenti a oggetti, ma anche valori di attributi (proprietà).

I membri dell'associazione sono chiamati suoi poli. Tutti i poli rappresentano i ruoli delle classi coinvolte nella connessione, sono distinti e possono essere elencati in qualche elenco ordinato. Nella maggior parte dei casi, le associazioni sono binarie (due ruoli in un'associazione con una determinata semantica), ma potrebbero anche esistere N -ario. Una stessa classe può agire in ruoli diversi, cioè trovarsi contemporaneamente in due poli dell'associazione.

Ai poli è indicata la molteplicità dei collegamenti.

Le connessioni possono apparire e scomparire durante il funzionamento del sistema; ai poli dell'associazione possono essere specificati vincoli e predicati corrispondenti.

A volte la connessione cambia solo su uno dei poli. Se un collegamento ha attributi, questi possono essere modificati dalle operazioni, tuttavia, i collegamenti ai partecipanti al collegamento non cambiano.

Un'associazione è rappresentata come una linea continua che collega i confini di 2 classi dell'associazione N-ary, quindi viene disegnato un rombo (segno di aggregazione):

		Molte associazioni - aggregazione
	Associazione binaria

I casi d'uso non scambiano messaggi tra loro e possono essere solo in relazioni (connessioni) estensioni(estendere) inclusione(includere) e generalizzazioni(generalizzazione).

IN per quanto riguarda l'espansione caso d'uso: il client introduce una sequenza aggiuntiva di azioni, a partire da un certo punto nella sequenza principale, e potrebbero esserci diversi "inserimenti" di questo tipo. Tutti questi punti sono chiamati punti di espansione.

Rational Unified Process (RUP) è una delle migliori metodologie di sviluppo software, creata da Rational Software. Basato sull'esperienza di numerosi progetti software di successo, il processo unificato consente di creare sistemi software complessi basati su metodi di sviluppo industriale. Uno dei pilastri principali su cui fa affidamento RUP è il processo di creazione di modelli utilizzando l'Unified Modeling Language (UML). Questo articolo riguarda l'utilizzo dei diagrammi UML nel flusso di lavoro di sviluppo di sistemi software utilizzando la metodologia Rational Software.

Non è un segreto che la creazione di software sia un processo complesso che, da un lato, ha molto in comune con la creatività e, dall'altro, sebbene sia altamente redditizio, è anche un'attività ad alto costo. La forte concorrenza nel mercato costringe gli sviluppatori a cercare metodi di lavoro più efficienti. Modi per creare sistemi software in tempi ancora più rapidi, a costi inferiori e con una qualità migliore. La complessità dei programmi è in costante aumento. Fino a poco tempo fa, i prodotti software potevano essere creati in un tempo prevedibile da singoli individui o, ad esempio, nel reparto IT di un'impresa automatizzata.

Al giorno d'oggi, a chi crea programmi in ginocchio viene lasciato il settore delle piccole utilità e dei vari moduli di estensione per prodotti software "pesanti". Il futuro appartiene all’approccio industriale alla creazione di software. Nel 1913 Henry Ford lanciò la prima catena di montaggio automobilistica e negli anni '90 una catena di montaggio simile iniziò ad essere utilizzata nel campo delle tecnologie IT. Lo sviluppo del team richiede un approccio completamente diverso e una metodologia diversa, che prima o poi doveva essere creata.

Rational Software Corporation (http://www.rational.com) ha rilasciato una knowledge base strutturata chiamata Rational Unified Process (RUP), che è un insieme di raccomandazioni complete per la creazione di quasi tutti i prodotti software. Avendo assorbito l'esperienza dei migliori sviluppi, RUP racconta in dettaglio quando, chi e cosa dovrebbe essere fatto nel progetto per ottenere un sistema software in tempo, con una certa funzionalità e nel rispetto del budget assegnato.

Il processo unificato può essere pensato come la somma delle varie attività della società di sviluppo necessarie a tradurre i requisiti del cliente in un sistema software. Un sistema che fornirebbe “risultati significativi” agli utenti e farebbe esattamente ciò che si aspettano dal sistema. Pertanto, il processo è controllato dai casi d'uso del sistema o, in caso contrario, dai precedenti.

Per implementare in tempo i requisiti del cliente, il Processo Unificato è suddiviso in fasi che consistono in iterazioni, motivo per cui il processo è anche chiamato iterativo e incrementale. Ogni iterazione attraversa un ciclo di lavoro di base e porta gli sviluppatori all'obiettivo finale: creare un sistema software. Durante le iterazioni vengono creati artefatti intermedi necessari per il completamento con successo del progetto e una versione del sistema software che implementa un determinato insieme di funzioni, che aumenta di iterazione in iterazione. Le fasi e i principali flussi di lavoro del processo sono mostrati in Fig. 1, vengono forniti anche i costi approssimativi della manodopera per fase.

riso. 1 Fasi del RUP e flussi di lavoro

Da notare che nella Fig. 1 mostra solo il lavoro principale del Processo Unificato. Ad esempio, le attività di gestione delle attività non vengono visualizzate qui per evitare di ingombrare il diagramma.

Tutto lo sviluppo del software è considerato in RUP come un processo di creazione di artefatti. Qualsiasi risultato del progetto, siano essi codici sorgente, moduli oggetto, documenti trasferiti all'utente, modelli: queste sono sottoclassi di tutti gli artefatti del progetto. Ogni membro del team di progetto crea i propri artefatti e ne è responsabile. Il programmatore crea il programma, il manager crea il piano di progetto e l'analista crea il modello di sistema. RUP consente di determinare quando, da chi e quale artefatto deve essere creato, modificato o utilizzato.

Una delle classi più interessanti di artefatti di progetto sono i modelli, che consentono agli sviluppatori di definire, visualizzare, costruire e documentare gli artefatti del sistema software. Ogni modello è una visione autonoma del sistema in fase di sviluppo ed è destinato sia a delineare i problemi che a proporre soluzioni. L'autosufficienza dei modelli significa che un analista o uno sviluppatore può ottenere tutte le informazioni di cui ha bisogno da un modello specifico senza ricorrere ad altre fonti.

I modelli consentono di considerare il sistema futuro, i suoi oggetti e la loro interazione anche prima di investire fondi significativi nello sviluppo, consentono di vederlo attraverso gli occhi dei futuri utenti dall'esterno e degli sviluppatori dall'interno ancor prima della prima riga del codice sorgente; è creato. La maggior parte dei modelli sono rappresentati da diagrammi UML; puoi leggere ulteriori informazioni su UML, ad esempio, in.

L’Unified Modeling Language è apparso tra la fine degli anni ’80 e l’inizio degli anni ’90, principalmente grazie agli sforzi dei “tre amici” Gradi Bucha, Jim Rambo e Ivar Jacobson. Ora è stato adottato dal consorzio OMG come linguaggio di modellazione standard che fornisce agli sviluppatori una notazione chiara che consente di visualizzare i modelli in elementi grafici generalmente accettati e compresi da tutti i partecipanti al progetto.

Tuttavia, non dovremmo dimenticare che il linguaggio di modellazione fornisce solo una notazione, uno strumento per descrivere e modellare un sistema, e un processo unificato determina la metodologia per l'utilizzo di questo strumento, così come altri strumenti di supporto metodologico di Rational. UML può essere utilizzato senza una metodologia specifica perché è indipendente dal processo e, indipendentemente dall'opzione di processo utilizzata, è possibile utilizzare i diagrammi per documentare le decisioni prese durante lo sviluppo e visualizzare i modelli creati.

Un sistema software viene creato per risolvere problemi specifici dell'utente e non per consentire ai programmatori di testare nuove tecnologie e acquisire esperienza per il project manager. In generale, all'utente non interessa se si utilizza un approccio orientato agli oggetti, UML, RUP o si crea un sistema utilizzando il metodo XP (programmazione estrema) nel processo di sviluppo. L'uso di determinati metodi, tecnologie e la creazione della struttura interna ottimale del progetto rimangono nella coscienza degli sviluppatori, che prendono decisioni in base all'esperienza precedente e alle proprie preferenze. Tuttavia, l'utente non ti perdonerà per aver ignorato le sue esigenze. Anche se un sistema software viene sviluppato dieci volte utilizzando metodi e tecnologie all’avanguardia, se l’utente non ottiene da esso quello che viene chiamato un “risultato significativo”, il progetto software fallirà miseramente.

Ne consegue che l'applicazione sconsiderata di UML, semplicemente perché è di moda, non solo non porterà lo sviluppo al successo, ma potrebbe anche causare insoddisfazione tra i dipendenti che hanno bisogno di studiare una grande quantità di letteratura aggiuntiva e tra i project manager quando si scopre che i costi della manodopera sul progetto aumentano e i rendimenti non aumentano. È necessario comprendere chiaramente cosa si desidera ottenere dall'implementazione di questa tecnologia e perseguire questo obiettivo. L'utilizzo di UML consente di risparmiare risorse di sviluppo perché consente di farsi un'idea del sistema più velocemente rispetto a quando si creano layout e prototipi, spendendo risorse incomparabilmente inferiori.

I diagrammi facilitano la comunicazione tra i membri del progetto e, cosa particolarmente preziosa, coinvolgono gli utenti finali del sistema nel processo. La modellazione consente di ridurre i rischi del progetto, poiché è sempre più facile per i programmatori fare ciò che è chiaro e comprensibile piuttosto che arrivare a un risultato incerto. La creazione di diagrammi è simile alla creazione di un progetto di costruzione: puoi farne a meno, ad esempio, quando costruisci un capannone in un cottage estivo, tuttavia, più grande è l'edificio (nel nostro caso, un prodotto software), più difficile è fare e tanto più incerto sarà il risultato finale.

Una volta ho tenuto un seminario su RUP presso un'azienda di software che aveva avuto un discreto successo sul mercato per dieci anni, ma non utilizzava affatto la modellazione nel suo flusso di lavoro, ma si basava su prototipi. Nella sala si sono riuniti una ventina di programmatori giovani ed esperti, che hanno ascoltato attentamente tutto ciò che ho detto loro su RUP e UML. E uno di loro, guardando la lavagna ricoperta di schemi esemplificativi, ha osservato: “Tutto questo è interessante e probabilmente utile per altri progetti”, ha detto, “ma lavoriamo da parecchio tempo senza tutto questo, poiché siamo tuttavia abbiamo fatto a meno di UML, probabilmente semplicemente non ne abbiamo bisogno.”

Questa domanda mi ha fatto pensare che il cambiamento nei processi aziendali che inevitabilmente deve verificarsi in una società di sviluppo software quando si implementa RUP e UML può essere difficile quanto l'implementazione di un sistema informativo in un'impresa industriale. Qualsiasi implementazione è una rottura degli stereotipi. Poiché le qualifiche dei dipendenti in una società di sviluppo software sono piuttosto elevate, per queste persone è più difficile abbandonare le proprie opinioni che per i "semplici mortali" e le difficoltà e il rifiuto che sorgono possono essere paragonati al passaggio dal procedurale all'oggetto. pensiero orientato.

1.Definizione dei requisiti

Un processo unificato è un processo guidato da casi d'uso che riflettono gli scenari di interazione dell'utente. In realtà, è la visione del sistema software da parte degli utenti dall'esterno. Pertanto, una delle fasi più importanti dello sviluppo, secondo RUP, sarà la fase di determinazione dei requisiti, che consiste nel raccogliere tutti i possibili desideri per il funzionamento del sistema che possono venire in mente solo agli utenti e agli analisti. Successivamente questi dati dovranno essere sistematizzati e strutturati, ma in questa fase, attraverso interviste agli utenti e studio di documenti, gli analisti devono raccogliere quanti più requisiti possibili per il sistema futuro, il che non è così semplice come sembra a prima vista. Gli utenti spesso non hanno idea di cosa dovrebbero ottenere alla fine. Per facilitare questo processo, gli analisti utilizzano diagrammi dei casi d'uso (Fig. 2)

Fig 2. Esempio di diagramma dei casi d'uso

Il diagramma riflette gli attori (attanti) che interagiscono con il sistema e la reazione degli oggetti software alle loro azioni. Gli attanti possono essere sia utenti che agenti esterni che necessitano di trasmettere o ricevere informazioni. L'icona del caso d'uso riflette la risposta del sistema all'input esterno e mostra cosa deve essere fatto per l'attante.

Per dettagliare un caso d'uso specifico, viene utilizzato un diagramma di attività, un esempio del quale è riportato nella Figura 3.

riso. 3 Esempio di diagramma di attività

La semplicità del diagramma dei casi d'uso consente agli analisti di comunicare facilmente con i clienti durante il processo di definizione dei requisiti, identificando i vincoli imposti al sistema e all'implementazione dei singoli requisiti, come i tempi di risposta del sistema, che successivamente rientrano nella sezione dei non funzionali requisiti.

Un diagramma dei casi d'uso può essere utilizzato anche per creare scenari di test poiché tutte le interazioni tra gli utenti e il sistema sono già state definite.

Per determinare correttamente i requisiti, gli sviluppatori devono comprendere il contesto (parte dell'area tematica) in cui funzionerà il futuro sistema. Per fare ciò vengono creati un modello di dominio e un modello di business, che rappresentano approcci diversi allo stesso problema. Spesso viene creata una cosa: un modello di dominio o un modello di business.

La differenza tra questi modelli è che il modello di dominio descrive i concetti importanti con cui funzionerà il sistema e le loro connessioni reciproche. Mentre un modello di business descrive i processi aziendali (esistenti o futuri) che il sistema dovrebbe supportare. Pertanto, oltre a definire gli oggetti aziendali coinvolti nel processo, questo modello definisce i lavoratori, le loro responsabilità e le azioni che devono compiere.

Per creare un modello di dominio viene utilizzato un normale diagramma di classi (Figura 6), ma chiaramente non è sufficiente per creare un modello di business. In questo caso, viene utilizzato un diagramma dei casi d'uso utilizzando icone aggiuntive che riflettono l'essenza dei processi aziendali: si tratta di attante aziendale, caso d'uso aziendale, entità aziendale e gestione aziendale. Questo modello è molto più vicino al modello successivo creato nel processo di sviluppo: il modello di analisi.

2.Analisi

Dopo aver determinato i requisiti e il contesto in cui opererà il sistema, è il momento di analizzare i dati ottenuti. Durante il processo di analisi viene creato un modello analitico che guida gli sviluppatori verso l'architettura del futuro sistema. Un modello analitico è una visione di un sistema dall'interno, in contrapposizione a un modello di casi d'uso, che mostra come apparirà il sistema dall'esterno.

Questo modello permette di capire come dovrebbe essere progettato il sistema, quali classi dovrebbe avere e come dovrebbero interagire tra loro. Il suo scopo principale è determinare la direzione di implementazione delle funzionalità identificate nella fase di raccolta dei requisiti e delineare l'architettura del sistema.

A differenza del modello di progettazione creato successivamente, il modello di analisi è più un modello concettuale e avvicina solo gli sviluppatori alle classi di implementazione. Questo modello non dovrebbe avere le possibili contraddizioni che possono verificarsi nel modello precedente.

Per visualizzare il modello di analisi utilizzando UML, viene utilizzato un diagramma di classe con stereotipi (modelli di comportamento) "classe limite", "entità", "controllo" e diagrammi di collaborazione vengono utilizzati per i dettagli (Figura 4). Lo stereotipo della "classe limite" descrive una classe che interagisce con attanti esterni, lo stereotipo dell'"entità" descrive classi che sono archivi dati e lo stereotipo del "controllo" descrive classi che gestiscono le query alle entità.

Figura 4. Esempio di diagramma di collaborazione

La numerazione dei messaggi ne mostra l'ordine, ma lo scopo del diagramma non è considerare l'ordine dei messaggi scambiati, bensì mostrare chiaramente le relazioni delle classi tra loro.

Se ci concentriamo sull'ordine di interazione, un'altra rappresentazione sarebbe un diagramma di sequenza (Sequenza), mostrato nella Figura 5. Questo diagramma consente di osservare lo scambio di messaggi nel tempo, visualizzando visivamente la sequenza del processo. Quando si utilizza uno strumento di creazione di modelli come Rational Rose, questi due tipi di diagrammi possono essere creati automaticamente l'uno dall'altro (puoi leggere ulteriori informazioni su Rational Rose, ad esempio, in).

Riso. 5 Esempio di diagramma di sequenza

La decisione su quale dei due diagrammi creare per primo dipende dalle preferenze del singolo sviluppatore. Poiché questi diagrammi sono una rappresentazione dello stesso processo, entrambi consentono di riflettere l'interazione tra gli oggetti.

3.Progettazione

La fase successiva nel processo di creazione di un sistema è la progettazione, durante la quale viene creato un modello di progettazione basato sui modelli creati in precedenza. Questo modello riflette l'implementazione fisica del sistema e descrive il prodotto creato a livello di classe e componente. A differenza del modello di analisi, il modello di progettazione ha una chiara dipendenza dalle condizioni di implementazione, dai linguaggi di programmazione e dai componenti utilizzati. Per una comprensione più accurata dell'architettura del sistema, questo modello dovrebbe essere quanto più formalizzato possibile e mantenuto aggiornato durante l'intero ciclo di vita dello sviluppo del sistema.

Per creare un modello di progettazione, viene utilizzata un'intera serie di diagrammi UML: diagrammi di classi (Fig. 5), diagrammi di cooperazione, diagrammi di interazione, diagrammi di attività.

Fig 6. Esempio di diagramma classi

Inoltre, questo flusso di lavoro può creare un modello di distribuzione implementato in base a un diagramma di distribuzione. Questo è il tipo di diagramma più semplice progettato per modellare la distribuzione dei dispositivi su una rete. Per la visualizzazione vengono utilizzate solo due opzioni per le icone del processore e del dispositivo, insieme alle connessioni tra loro.

4.Implementazione

Il compito principale del processo di implementazione è creare un sistema sotto forma di componenti: codici sorgente del programma, script, file binari, moduli eseguibili, ecc. In questa fase viene creato un modello di implementazione che descrive come vengono implementati gli elementi del modello di progettazione e quali classi saranno incluse in componenti specifici. Questo modello descrive il modo di organizzare questi componenti secondo i meccanismi di strutturazione e modularizzazione adottati nell'ambiente di programmazione selezionato ed è rappresentato da uno schema dei componenti (Fig. 7).

riso. 7 Esempio di schema dei componenti

5.Test

Durante il processo di test vengono controllati i risultati dell'implementazione. Per questo processo viene creato un modello di test, che consiste in casi di test, procedure di test, componenti di test, ma non ha una rappresentazione del diagramma UML, quindi non ci soffermeremo su di esso.

6. Conclusione

Qui sono stati considerati solo i principali processi della metodologia Rational. RUP è piuttosto ampio e contiene raccomandazioni per l'esecuzione di vari progetti software, dalla creazione di programmi da parte di un gruppo di sviluppatori composto da più persone, a progetti software distribuiti che uniscono migliaia di persone in diversi continenti. Tuttavia, nonostante le enormi differenze, le modalità di utilizzo dei modelli creati utilizzando UML saranno le stesse. I diagrammi UML, creati in varie fasi di sviluppo, sono inseparabili dal resto degli artefatti di un progetto software e spesso costituiscono il collegamento tra i singoli processi RUP.

La decisione di utilizzare schemi specifici dipende dal processo di sviluppo impostato in azienda, che, anche se chiamato unificato, non è qualcosa di congelato. Rational non si limita a migliorarlo e perfezionarlo, ma fornisce anche strumenti speciali per apportare modifiche al database RUP.

Ma in ogni caso, l'uso di UML insieme a un processo unificato consentirà di ottenere un risultato prevedibile, rispettare il budget assegnato, aumentare l'impatto dei partecipanti al progetto e la qualità del prodotto software creato.

Kratchen. F. Introduzione Processo razionale unificato . Ed. 2° - M.: Williams Publishing House, 2002. - 240 pp.: ill.

Jacobson A., Buch G., Rambo J. Processo di sviluppo software unificato - San Pietroburgo: Peter, 2002. - 496 pp.: ill.

Fowler M., Scott K. UML in poche parole. Applicazione di un linguaggio standard di modellazione di oggetti: Transl. dall'inglese – M.:Mir, 1999. – 191 p., illustrato.

Beck. E. Programmazione estrema. – San Pietroburgo: Pietro, 2002. – 224 p.: ill.

Trofimov S. Tecnologie CASE: lavoro pratico in Rational Rose.
Ed. 2° - M.: Binom-Press, 2002 - 288 p.

Unified Process utilizza attivamente il linguaggio di modellazione unificato ( UML). Nel nucleo UML si trova un modello che consente al team di sviluppo di comprendere in modo semplificato la varietà di processi complessi richiesti per lo sviluppo del software. Vari modelli utilizzati in Processo unificato, consentono di visualizzare il sistema, descriverne la struttura e il comportamento e documentare le decisioni prese durante il processo di sviluppo.

Storia dell'origine

Le origini del quadro risiedono nel lavoro di un dipendente Ericsson Ivar Jacobson, pubblicato alla fine degli anni '60. Jacobson e i suoi colleghi modellarono enormi sistemi di telecomunicazioni utilizzando strati di “blocchi” (quelli che in seguito divennero noti come “componenti”): gli strati inferiori servivano come base per i sottosistemi degli strati superiori. Il team ha costruito i blocchi inferiori considerando i “casi di traffico” che potrebbero verificarsi agli utenti del sistema. Sono stati questi “incidenti” a diventare il prototipo dei casi d’uso, nei quali sono stati successivamente inclusi UML. Il lavoro di Jacobson ha ispirato anche la creazione dei diagrammi utilizzati in UML, compresi i diagrammi di attività e sequenza.

Nel 1987 Jacobson fondò la propria azienda Obiezione AB e insieme ai partner hanno trascorso diversi anni a sviluppare un progetto e un prodotto chiamato Obiezione. Nel 1995 Jacobson pubblicò il libro “ Ingegneria del software orientata agli oggetti”, descrivendo un processo di sviluppo guidato dai requisiti del cliente che si traducono nel prodotto finale attraverso casi d'uso. L'uscita del libro ha coinciso con la prima pubblicazione della versione online del kernel Processo unificato.

Nel 1995 l'azienda Obiezione AB assorbito dalla corporazione Razionale. Con l'aiuto di un numero significativamente maggiore di colleghi, Jacobson inizia ad espandere il processo Obiezione, completandolo con strumenti per la gestione e lo sviluppo dei progetti. Insieme a Grady Booch e James Rumbaugh, che lavoravano lì Razionale in precedenza, Jacobson divenne membro del gruppo dei “tre amigos”, che guidò il lavoro per creare un processo chiamato Processo di obiezione razionale (ROP), nonché la distribuzione Processo unificato, che è diventato la base per Linguaggio di modellazione unificato.

In fase di lavorazione ROP E UML, società Razionale continue fusioni e acquisizioni di aziende coinvolte nella creazione di strumenti di sviluppo software. Questi strumenti fornivano funzionalità per la gestione dei requisiti (“RequisitePro”), test generali (“SQA”), test delle prestazioni, gestione della configurazione e gestione delle modifiche. Nel 1998 Razionale cambia il nome del prodotto in RUP, il cui nucleo concettuale rimane Processo unificato.

Caratteristiche

Processo unificato basato su casi d'uso, descrivendo uno o più attori che interagiscono con il sistema e ottengono risultati preziosi per i partecipanti al processo. Sono i casi d'uso la principale forza trainante che guida l'intero processo di sviluppo, a partire dalla raccolta e discussione dei requisiti, per finire con l'analisi, la progettazione e l'implementazione. I casi d'uso sono descritti con un linguaggio semplice e comprensibile, in modo da risultare comprensibili anche ad un lettore esterno.

Secondo Processo unificato, al centro del processo di sviluppo si trova architettura- l'organizzazione fondamentale dell'intero sistema. Può includere elementi statici e dinamici, la loro interazione e consente di risolvere problemi di efficienza del prodotto, estensibilità, capacità di riutilizzare gli elementi e aiutare a superare limitazioni economiche e tecniche. Il team di progetto inizia a lavorare sulla descrizione dell'architettura il prima possibile e la espande e migliora costantemente durante il processo di sviluppo. L'architettura è considerata un aspetto importante Processo unificato per una serie di ragioni, la chiave delle quali è la capacità di vedere il quadro completo di ciò che sta accadendo, la corretta applicazione degli sforzi degli sviluppatori, la facilitazione delle opportunità di riutilizzo dei componenti, lo sviluppo del sistema e la corretta selezione dei casi d'uso.

Il terzo principio fondamentale Processo unificatoè l'uso approccio iterativo e incrementale. Le iterazioni sono progetti in miniatura che consentono di avviare una versione più recente del sistema. Il risultato dell'iterazione, ovvero le modifiche apportate al sistema, è chiamato incremento. In particolare, l'approccio iterativo consente di migliorare costantemente l'architettura del sistema, gestire i continui cambiamenti dei requisiti e adattare in modo flessibile il piano dell'intero progetto. L'impegno verso il principio dell'integrazione continua consente di identificare tempestivamente possibili problemi. Inoltre, l'iterazione aiuta a ridurre al minimo i rischi associati ai vincoli tecnici, all'architettura e alla modifica dei requisiti.

Fasi di sviluppo

Dimensione relativa delle fasi di sviluppo per un progetto tipico

Ogni ciclo di sviluppo, secondo Processo unificato, è composto da quattro fasi, che rappresentano il periodo di tempo tra importanti traguardi del progetto, consentendo ai manager di prendere decisioni importanti riguardanti la continuazione del processo di sviluppo, l'ambito di lavoro, il budget e il programma.

Varietà del flusso di lavoro

Dentro Processo unificato In ogni fase di sviluppo, ci sono cinque tipi di processi di lavoro: requisiti, analisi, progettazione, implementazione e test.

Ogni processo è un insieme di attività eseguite da diversi membri del team di progetto. Pertanto, l’obiettivo dei processi di raccolta dei requisiti è quello di creare un modello di casi d’uso che consenta di identificare i requisiti funzionali di base per il sistema. I processi di analisi e il modello corrispondente consentono agli sviluppatori di strutturare i requisiti funzionali; Il processo di progettazione descrive l'implementazione fisica dei casi d'uso ed è un'astrazione per il modello seguente. Il processo e il modello di implementazione descrivono come gli elementi di progettazione si relazionano ai componenti software, incluso il codice sorgente, le librerie dinamiche, ecc. L'ultimo modello, che descrive i test, spiega quali test di sistema e test unitari dovrebbero essere eseguiti e come dovrebbe eseguirli il team di sviluppo.

Iterazioni e incrementi

Ciascuna delle fasi descritte nel Processo Unificato è composta da iterazioni, che sono sottoprogetti in miniatura di durata limitata. In genere, ciascuna iterazione include tutti e cinque gli elementi del flusso di lavoro a vari livelli. Il risultato dell'iterazione è incremento, una release contenente miglioramenti rispetto alla versione precedente del prodotto.

Processo razionale unificato(RUP) è un framework tecnologico di sviluppo software sviluppato e commercializzato da Rational Software. Incorpora le migliori pratiche globali nello sviluppo di software e fornisce un approccio disciplinare all'assegnazione e alla gestione di compiti e responsabilità all'interno di un'organizzazione di sviluppo software. Applicando questo processo, i team di sviluppo software saranno in grado di creare software di alta qualità che soddisfi le esigenze dei loro utenti finali e di farlo entro tempi e budget prevedibili.

RUP guida i professionisti del software ad applicare in modo efficace le migliori pratiche attuali come sviluppo iterativo, applicazione approccio incentrato sull'architettura, casi d'uso, riduzione del rischio in tutte le fasi del processo e verifica continua del programma.

Il Rational Unified Process si basa su diversi principi fondamentali, raccolti da numerosi progetti di successo:

· Iniziate ad attaccare i rischi principali prima e fatelo continuamente, altrimenti loro stessi passeranno all'offensiva contro di voi.

· Garantire che i requisiti del cliente siano soddisfatti.

· Concentrarsi sul programma in esecuzione.

· Adattarsi al cambiamento fin dall'inizio del progetto.

· Stabilire tempestivamente l'architettura eseguibile.

· Costruisci un sistema partendo da componenti.

·Lavorare insieme come una squadra.

· Fare della qualità uno stile di vita e non un ripensamento.

RUP utilizza approccio iterativo Ogni iterazione esegue un po' di lavoro sui requisiti, analisi, progettazione, implementazione e test. Ogni iterazione si basa sui risultati delle iterazioni precedenti e produce un programma eseguibile che si avvicina sempre di più al prodotto finale.

RUP fornisce approccio strutturato allo sviluppo iterativo, dividendo il progetto in quattro fasi: Inception, Design, Construction e Implementation. Ogni fase è accompagnata da una cosiddetta pietra miliare, un punto di controllo del processo, in cui viene verificato il raggiungimento degli obiettivi della fase successiva e viene presa una decisione sulla transizione (o meno) alla fase successiva. Ciascuna delle quattro fasi del RUP ha quindi una pietra miliare e una serie di obiettivi chiaramente definiti. Questi obiettivi vengono utilizzati per determinare quali attività eseguire e quali artefatti creare. Ogni fase si concentra rigorosamente su ciò che è necessario solo per raggiungere gli obiettivi aziendali della fase.

Tutti gli elementi del processo - ruoli, compiti, artefatti e correlati concetti, guide e modelli raggruppati in contenitori logici chiamati Discipline(Discipline). Ci sono solo nove discipline nel prodotto RUP standard. Questi includono: modellazione aziendale, gestione dei requisiti, gestione dei progetti, gestione del cambiamento e ambiente.

Ogni flusso di lavoro del processo: raccolta dei requisiti, analisi, progettazione, implementazione e test definisce una serie di artefatti e attività associati. Ricordiamo che un artefatto è un documento, un report, un elemento eseguibile, ecc. Artefatto possono essere prodotti, trasformati o consumati.

Modello- il tipo più importante di artefatto. Vengono forniti nove modelli, che insieme coprono tutte le soluzioni per la visualizzazione, la specifica, la progettazione e la documentazione dei sistemi software:

· modello di business. Definisce l'astrazione dell'organizzazione per la quale viene creato il sistema;

· modello di dominio. Corregge l'ambiente contestuale del sistema;

· Caso d'uso del modello. Definisce i requisiti funzionali del sistema.

· modello di analisi. Interpreta i requisiti di sistema in termini di modello di progettazione;

· modello di progettazione. Definisce il vocabolario di dominio del problema e la sua soluzione;

· modello di posizionamento. Definisce la topologia hardware in cui viene eseguito il sistema;

· modello di implementazione. Definisce le parti utilizzate per assemblare e implementare un sistema fisico;

· modello di prova. Definisce casi di test per verificare il sistema;

· modello di processo. Definisce il parallelismo nel sistema e i meccanismi di sincronizzazione.

Artefatti tecnici sono divisi in quattro gruppi principali:

· insieme di requisiti. Descrive Che cosa il sistema dovrebbe fare;

· insieme di progettazione.

· insieme di implementazioni. Descrive l'assemblaggio dei componenti software sviluppati;

· set di posizionamento. Fornisce tutte le informazioni sulla configurazione fornita.

Insieme di requisiti può includere un modello di caso d'uso, un modello di requisiti non funzionali, un modello di dominio, un modello di analisi e altre forme di espressione delle esigenze dell'utente.

Insieme di progettazione può includere un modello di progettazione, un modello di test e altre forme di espressione dell'essenza del sistema.

Insieme di implementazioni raggruppa tutti i dati sugli elementi software che compongono il sistema (codice del programma, file di configurazione, file di dati, componenti software, informazioni sull'assemblaggio del sistema).

Insieme di posizionamento raggruppa tutte le informazioni relative all'imballaggio, alla spedizione, all'installazione e all'avvio del sistema.

Ogni processo tecnologico è accompagnato rischio. Quando si sviluppa un prodotto software, un risultato insoddisfacente (ONU) può essere: superamento del budget, bassa affidabilità, funzionamento errato, ecc. L'impatto del rischio viene calcolato utilizzando l'espressione

Indicatore di rischio = Probabilità (LP) * Perdita (LP).

Gestione del rischio comprende sei azioni:

1. Identificazione del rischio: identificare gli elementi di rischio nel progetto.

2. Analisi del rischio: valutazione della probabilità e dell'entità della perdita per ciascun elemento di rischio.

3. Classificazione del rischio: ordinare gli elementi di rischio in base al grado della loro influenza.

4. Pianificazione della gestione del rischio: preparazione ad affrontare ciascun elemento di rischio.

5. Risoluzione del rischio – eliminazione o risoluzione degli elementi di rischio.

6. Monitoraggio del rischio – monitorare la dinamica degli elementi di rischio, intraprendendo azioni correttive.

Le prime tre azioni appartengono alla fase di valutazione del rischio, le ultime tre azioni alla fase di controllo del rischio.

Esistono tre categorie di fonti di rischio: rischio di progetto, rischio tecnico e rischio commerciale. Dopo aver identificato gli elementi di rischio, è necessario quantificare il loro impatto sul progetto software e risolvere le domande sulle possibili perdite. Questi problemi vengono affrontati durante la fase di analisi del rischio. Infine, nel piano generale del progetto software è integrato un piano per la gestione di ciascun elemento di rischio, ovvero un insieme di funzioni per la gestione di ciascun elemento di rischio.