Approfondimenti di programmazione

PROCESSO DI SVILUPPO

Come già menzionato, l'UML prese spunto da un insieme di metodi di progetto e di analisi Object Oriented. Per estensione, tutti questi metodi si mescolarono in un linguaggio di modellazione grafica con un processo che descrive come sviluppare un software. Interessante, oltre al come fu formato l'UML, è che i vari attori scoprirono che, anche se loro potessero essere d'accordo su un unico linguaggio di modellistica, sicuramente non potevano essere d'accordo su un processo. Come risultato, i vari attori concordarono sul fatto di partire dalla modellazione grafica trascendendo dal processo, implementato solo dopo a seconda dei vari e diversi punti di vista. Comunque, non crediamo che la modellazione tecnica abbia alcun senso senza che si sappia come debba avanzare il processo. Il modo in cui si usa l'UML dipende molto dallo stile del processo che si usa. È importante parlare del processo prima così da capire il contesto.

in cui usare l'UML.

Quando si sentono persone discutere sull'UML, si sente parlare spesso del Rational Unified Process (RUP), Processo Unificato e Razionale. RUP è uno (o più) processo (/i) strutturale che viene usato insieme all'UML. Quindi questo processo supporta l'UML ma non è il solo a poter essere usato, anche se è il più comune.

Processi Iterativi e a cascata. Uno dei più grandi dibattiti sul processo è quello tra stili a cascata ed iterativi. I termini spesso sono adoperati male, particolarmente per "iterativi". Come risultato, molti progetti chiedono di sviluppare con stili iterativi ma stanno facendo ricorso anche a modelli a cascata.

La differenza essenziale tra i due è che si può suddividere un progetto in piccoli pezzi. Se si ha un progetto che si pensa finisca a lungo termine, poche persone possono decidere di prendersi il proprio pezzo del progetto e consegnarlo indipendentemente.

suddividendo il carico di lavoro
Ogni persona può trovare un diverso approccio al proprio problema e tracciare una possibile evoluzione.
Le interruzioni di stile di cascata suddividono il progetto in base alle attività. Nel realizzare un software, si devono intraprendere certe attività: analisi dei requisiti, progettazione, programmazione e validazione.
È probabile che il nostro progetto sia costituito da una fase di analisi lunga 2 mesi, seguita da una fase di progettazione di 4 mesi, seguita da una fase di programmazione di 3 mesi, seguita da una fase di validazione di 3 mesi.
Lo stile di analisi ad iterazione divide il progetto in sottoinsiemi di funzionalità.
Qualora si desidera rivedere qualche fase per inserire nuove modifiche, il modello ad iterazione risulta il più vantaggioso. Molti scrittori di processi software negli ultimi anni, specialmente nella comunità orientata agli oggetti, sconsigliano un approccio di tipo a cascata. Tra lemolte ragioni, la più rilevante è che esso è molto difficile da spiegare e impiegare, e solitamente all'interno di un progetto vige sempre l'esigenza di inserire integrazioni e verifiche continue, per cui deve essere continuamente "manomesso", cosa non possibile con l'approccio a cascata. La comunità dell'OO è quindi d'accordo nell'utilizzare l'approccio iterativo e lo stesso UML è a favore di una vasta varietà di forme di sviluppo iterative. Tuttavia, nelle industrie e nella pratica vige ancora l'adozione di un approccio a cascata, anche se in realtà è una forma di sviluppo pseudoiterativo, ovvero si apportano correzioni ad un processo sviluppato in un modello a cascata. Al di là di tutto, testing e integrazione sono le attività più delicate da affrontare. Una comune tecnica di iterazione usata è quella detta time boxing, in cui si forza una

Iterazione ad avere un lasso di tempo fissato. L'analisi dei requisiti è un'attività, all'interno del ciclo di sviluppo di un software, in cui si cercano le figure coinvolte, gli utenti e i programmatori di un software che implementa funzionalità da specificate. Un numero di tecniche UML da http://www.quellidiinformatica.org - La community studenti di Ingegneria Informatica di Napoli. FranK 7 INGEGNERIA DEL SOFTWARE - UML usare sono le seguenti: casi d'uso, che descrivono come i personaggi interagiscono con il sistema; un class diagram che rappresenta la prospettiva concettuale, grazie al quale si costruisce un rigoroso vocabolario del dominio applicativo; un activity diagram, che mostra il flusso di lavoro dell'organizzazione, mostrando come il software e le attività umane interagiscono tra loro (un activity diagram può mostrare il contesto per i casi d'uso e anche i dettagli di come un complicato caso d'uso).

lavora); uno state diagram, che viene usato per rappresentare il ciclo di vita di un concetto, con ivari cambiamenti e eventi che cambiano il suo comportamento e le sue proprietà.Quando si lavora all’analisi dei requisiti, si deve ricordare che la comunicazione tra gli utenti e gli sviluppatori è divitale importanza. Solitamente, ci sono persone che non hanno buona familiarità con l’UML e le sue tecniche, matuttavia la sua adozione garantisce praticità e velocità di sviluppo, inserendo notazioni minime e standard, senzaspecifiche introduzioni nell’implementazione del software. L’introduzione di diagrammi e funzionalità che non fannocapire l’utente su come funziona il dominio peggiora le cose invece di aiutare.

CLASS DIAGRAMSono i componenti più evidenti ed usati in UML. Essi sono soggetti a una grande varietà di concetti di modellazione.Con semplici elementi base, vengono abbandonati i concetti

avanzati di difficile comprensione. Tuttavia anche nella trattazione dei diagrammi di classe c'è una parte elementare base e una parte avanzata. Un class diagram descrive i tipi di oggetti nel sistema e le varie relazioni che esistono tra essi. Esso mostra anche le proprietà e le operazioni di una classe e i vincoli che sono applicati agli oggetti che sono connessi. In UML si usa il termine caratteristica (feature) per indicare le proprietà possedute e le operazioni di una classe. Una classe è rappresentata come un rettangolo con tre campi particolari: il nome della classe (in grassetto), i suoi attributi e le sue operazioni. Inoltre altri concetti essenziali sono le associazioni e le generalizzazioni. Le proprietà rappresentano le caratteristiche strutturali di una classe. Le proprietà potrebbero essere i campi che compaiono in una classe. Le proprietà sono i singoli concetti, che appaiono sotto forma di due differenti notazioni: attributi e associazioni.

Gli attributi descrivono una proprietà in una linea di testo nel rettangolo della classe stessa. La notazione estesa per un attributo è la seguente: visibility name: type multiplicity = default {property-string} – La community studenti di Ingegneria Informatica di Napoli

FranK 8 INGEGNERIA DEL SOFTWARE - UML- name: String [1] = “Untitled” {readOnly} Solo il nome è necessario. Quando si mette + l’attributo è pubblico, se si mette – è privato. L’attributo corrisponde al nome di un campo in un linguaggio di programmazione. Il tipo di un attributo indica una restrizione sul genere di oggetto che si può trovare nell’attributo. Non è altro che il corrispondente tipo di un campo nel linguaggio di programmazione. Il valore di default indica il valore che inizializza un oggetto creato se nell’attributo non viene specificato durante la creazione. Inoltre {property-string}

indicare il numero minimo e massimo di oggetti che possono soddisfare una proprietà. Ad esempio, 1..* indica che la molteplicità è da uno a molti, mentre 0..1 indica che la molteplicità è da zero a uno. Le proprietà possono essere specificate utilizzando l'attributo "readOnly". Se viene utilizzato questo attributo, gli utenti non possono modificare la proprietà. Se non viene specificato, gli utenti possono modificare l'attributo. Le associazioni, invece, rappresentano un altro modo per segnalare le proprietà. Le associazioni sono linee che collegano due classi, partendo da una classe sorgente e arrivando a una classe target. Il nome della proprietà è scritto vicino alla classe target, indicando anche la molteplicità. La molteplicità di una proprietà indica quanti oggetti possono soddisfare quella proprietà. Le molteplicità più comuni sono: - 1 (uno a uno) - 0..1 (zero a uno) - * (indefinita, zero o molti) Generalmente, la molteplicità viene indicata con un limite superiore e inferiore per indicare il numero minimo e massimo di oggetti che possono soddisfare la proprietà.

Fissare il massimo e minimo valore delle occorrenze che partecipano in una associazione. Se i due limiti coincidono allora si usa un solo numero. La molteplicità è indicata anche per gli attributi e non solo per le associazioni. Per default le associazioni sono bidirezionali, ma è possibile esprimere anche delle associazioni unidirezionali. Un'associazione è bidirezionale qualora esprime una proprietà in un modo diretto ed inverso. http://www.quellidiinformatica.org - La community studenti di Ingegneria Informatica di Napoli FranK 9 INGEGNERIA DEL SOFTWARE - UML

In genere, per le associazioni unidirezionali si usano come nomi dei verbi, per indicare la transizione tra una classe sorgente a quella target.

Le operazioni sono le azioni che una classe conosciuta deve intraprendere o può intraprendere. Le operazioni corrispondono ai metodi di una classe. Anche in questo caso, le operazioni possono essere definite pubbliche o private (visibilità).

viene indicata la lista di parametri che gli vengono passati e il tipo di dati ritornato, con ulteriori proprietà da passare e applicare al metodo. <visibility> name (parameter-list) : return-type {property-string} Con le operazioni si specifica quella che viene chiamata interfaccia di una classe. Le operazioni possono modificare lo stato di una classe o semplicemente interrogare una classe (query). Queste ultime operazioni sono distinte in UML con il termine query, invece quelle che modificano lo stato di una classe sono dette modificatori. Altra distinzione da fare è quella delle operazioni che settano o prelevano un valore (getting method e setting method) in o da un campo. Un'operazione è solitamente un'azione invocata e desiderata su un oggetto, che implementa il metodo della classe. Qualora diverse classi appartenenti ad una gerarchia implementano la stessa funzionalità e, dunque, lo stesso metodo adattandolo all'oggetto specializzato, allora si.nte dal tipo dell'oggetto su cui viene invocato, mentre l'operazione è l'azione specifica che viene eseguita da quel metodo su un determinato tipo di oggetto. Il polimorfismo permette quindi di utilizzare un metodo in modo generico, senza dover conoscere il tipo specifico dell'oggetto su cui viene invocato. Questo rende il codice più flessibile e riutilizzabile, in quanto è possibile utilizzare lo stesso metodo su diversi tipi di oggetti, purché implementino l'interfaccia o la classe astratta corrispondente.