Che materia stai cercando?

Approfondimenti di programmazione Appunti scolastici Premium

Appunti di ingegneria del software della professoressa Fasolino. Il file contiene una trattazione su: la programmazione orientata agli oggetti (completa dell'analisi storica), l'UML (linguaggio di modellazione unificato), la OOP e le relazioni di ereditarietà.

Esame di Fondamenti di informatica docente Prof. R. Fassolino

Anteprima

ESTRATTO DOCUMENTO

FranK 2 INGEGNERIA DEL SOFTWARE - UML

sistemi software costruiti usando il paradigma object oriented (00), ovvero orientato agli oggetti. Questa è una

definizione piuttosto semplificata. Infatti, l'UML può essere inteso in diversi modi e da persone diverse. Ciò è dovuto

dalla sua propria storia e dai diversi punti di vista che le persone hanno quando si progetta uno specifico software.

Quindi l'UML è visto in modi diversi a seconda di chi lo usa e dei suoi scopi.

I linguaggi di modellazione grafica sono stati impiegati nell'industria software da lungo tempo. Il motivo della loro

importanza e del loro impiego sta nel fatto che i linguaggi di programmazione non forniscono meccanismi di astrazione

troppo ad alto livello che facilitino la discussione durante il processo di sviluppo e progettazione.

Nonostante il fatto che i linguaggi di modellazione grafica sono stati oggetti di lunghe dispute, specie nell'industria

software, riguardo il loro ruolo all'interno del processo di sviluppo. Tali dispute sono dovute proprio a come

indirettamente le persone percepiscono il ruolo

dell'UML stesso.

L'UML è uno standard relativamente aperto, controllato dall'Object Management Group (OMG), un libero consorzio di

società. L'OMG è stato formato per realizzare standard che supportino l’interoperabilità, specificamente

l'interoperabilità dei sistemi orientati agli oggetti. L'OMG forse è conosciuto meglio per gli standard

CORBA (Common Object Request Broker Architecture).

L'UML fu ideato per unificare i molti linguaggi di modellazione grafica orientati agli oggetti che erano stati sviluppati

alla fine degli anni ottanta e inizio anni novanta. Fin dalla sua apparizione nel 1997, ha cercato di risolvere e unificare

questa storica e particolare "torre di Babele", costituita dalla presenza di diversi e molti linguaggi.

Modi di usare UML

L’importanza dell’UML nello sviluppo di software è dovuta ai diversi modi in cui vari personaggi possono usarlo,

differenze che lo evidenziano da altri linguaggi di modellazione grafica. Questi vantaggi tuttavia creano discussioni

lunghe ed evidenti su come l’UML dovrebbe essere usato.

Per risolvere questo problema siamo arrivati a differenziare tre modi in cui le persone usano l’UML: disegno, formule e

linguaggio di programmazione. Sicuramente, il più comune dei tre, almeno secondo me è l’UML visto disegno, come

meccanismo di rappresentazione. In questo modo, sviluppatori usano l’UML per aiutare a comunicare alcuni aspetti di

un sistema. Anche con le formule, si possono usare dei meccanismi di rappresentazione per la cosiddetta

ingegnerizzazione diretta e ingegnerizzazione inversa. La Forward-engineering crea il diagramma UML prima d’aver

scritto il codice, mentre la reverse engineering costruisce il diagramma dal codice che già esiste per capirlo meglio.

L’essenza del disegnare è la selettività. Con la rappresentazione diretta si possono progettare in brutta copia dei

problemi in codice che si sta per scrivere, di solito discutendoli con le persone della propria equipe. L’intenzione è di

usare i disegni per aiutare a comunicare idee e alternative su quello che si sta per fare. Non si deve discutere tutto il

codice a cui si sta lavorando, ma solo problemi importanti che si vogliono prima discutere con i colleghi o sezioni del

disegno che si vuole visualizzare prima d’iniziare a programmare.

Con la reverse engineering si usano i disegni per spiegare come una parte del sistema funziona. Non si deve mostrare

ogni classe, ma semplicemente quelle che sono interessanti e quelle di cui vale la pena parlare, prima che si inizi la

discussione del codice.

Siccome disegnare è abbastanza informale e dinamico, lo si deve farlo velocemente, usando degli strumenti di sviluppo.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK 3 INGEGNERIA DEL SOFTWARE - UML

Nella reverse engineering le formule devono comunicare informazione dettagliate sul codice o in forma documentaria o

come grafica. Le formule possono far vedere ogni dettaglio su una classe in forma grafica ed è più facile per gli

sviluppatori comprendere.

La rappresentazione richiede tools molto più sofisticati per i disegni per trattare i dettagli richiesti per questo lavoro.

Tali tools sono i CASE (computer Aided Software Engineering).

Un po’ di storia

Negli anni 80, gli oggetti incominciavano a muoversi dal laboratorio al mondo reale. Smalltalk si stabilizzò in una

piattaforma che poteva essere usata dalla gente, ed e’ nato C++. Allo stesso tempo, le persone incominciavano a pensare

all’object-oriented graphical design languages.

Persone di riguardo: Grady Booch (Booch OOAD), Peter Coad (Coad OOA, Coad OOD), Ivar Jacobson (Objectory,

OOSE), Jim Odell, Jim Rumbaugh (OMT), Sally Schlaer and Steve Mellor (states), e Rebecca Wirfs-Brock

(Responsibility driven design).

Questi autori informalmente guidavano gruppi di lavoro concordi, tutti usanti metodi erano simili, ma contenevano delle

piccole differenze fra di loro. Gli stessi concetti apparivano in diversi notazioni, e ciò causava confusione.

Durante questo periodo, si parlava di standardizzazione, ma si ignorava. Un equipe dall’OMG cominciò a guardare alla

standardizzazione.

L’evento che innescò la nascita dell’UML fu quando Jim Rumbaugh lasciò la GE per raggiungere Grady Booch alla

Rational (ora fa parte di IBM). Booch/Rumbaugh dall’inizio era stata vista come un’alleanza che poteva attirare le

industrie software del settore. La “guerra dei metodi” terminò, anche se le aziende varie si mettono i bastoni tra le ruote

nel creare nuovi metodi e linguaggi.

Quando le persone parlano di UML, creditano di solito Grady Booch, Ivar Jacobson, e Jim Rumbaugh il nome di

creatori. Sono spesso chiamati, I Three Amigos.

Notations and Meta-Models

Nello stato corrente, UML definisce una notazione e anche una meta-modello. La notazione è la parte grafica che si

vede nei modelli, la sintassi grafica del linguaggio di modellazione. Per esempio, La notazione dei class diagram

definisce concetti, come classi, associazioni ecc.

Che cos’è il Legal UML?

Al primo impatto questa dovrebbe essere una semplice domanda da rispondere: il Legal UML è ciò che è definito come

ben disposto nella specificazione. Comunque, praticamente la risposta è un po’ più complicata.

Una parte importante di questa domanda è se l’UML ha regole descrittive o prescrittive. Un linguaggio con regole

prescrittive è controllato da un corpo ufficiale che afferma ciò che è o non è legale nel linguaggio e ciò significa che tu

dai espressioni a quel linguaggio. Un linguaggio con regole descrittive è quello in cui tu capisci le sue regole

guardando come la gente usa il linguaggio praticamente. I linguaggi di programmazione badano ad avere regole

prescrittive poste da un comitato di standards o da un venditore dominante, mentre lingue naturali come l’Inglese,

tendono ad avere regole descrittive il cui significato è posto per convenzione.

UML è piuttosto un linguaggio preciso, quindi è probabile che tu aspetti di avere regole prescrittive. Ma l’UML è

spesso considerato per essere il software equivalente dei blueprints in altre discipline ingegneristiche, e questi blueprints

non sono notazioni prescrittive. Non la commissione dice cosa sono i simboli legali su un disegno di ingegneria

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK 4 INGEGNERIA DEL SOFTWARE - UML

strutturale; la notazione è stata accettata per convenzione, similmente ad un linguaggio naturale. Insomma, l’UML è

così complicato che lo standard è spesso aperto a multiple interpretazioni. Anche i leader dell’UML che hanno visto

questo libro non sarebbero d’accordo sull’interpretazione dello standard UML.

Se tu vuoi capire un diagramma UML, è importante realizzarlo per capire che l’UML standard non è tutta descrizione.

La gente adotta convenzioni, sia largamente nell’industria e dentro un progetto particolare. Come risultato, anche se

l’UML standard può essere il mezzo primario di informazione sull’UML, non può essere il solo.

La mia attitudine è che, per molta gente, l’UML ha regole descrittive. L’UML standard è la più grande singola influenza

su ciò che l’UML significa ma non è l’unico. Io penso che questo diventi particolarmente preciso con UML2 che

introduce alcune convenzioni notazionali che contrasta con l’altra definizione dell’UML1 o l’uso convenzionale

dell’UML, così come aggiunge ancora più complessità all’UML. In questo libro, quindi, sto cercando di riassumere

l’UML come l’ho trovato: sia gli standards che l’uso convenzionale. Quando devo fare una distinzione in questo libro,

userò il termine uso convenzionale per indicare qualcosa che non è nello standard ma che io penso è largamente usato.

Per qualcosa che si conformerà allo standard, userò il termine standard o normativo. (Normativo è il termine standards

che la gente usa per intendere un’affermazione che tu devi conformare affinchè sia valida nello standard. Così il non-

normativo UML è un modo della fantasia per dire che qualcosa è severamente illegale in conformità allo standard

UML).

Quando tu guardi un diagramma UML, tu dovresti serbare nella mente che un principio generale nell’UML è che ogni

informazione può essere soppressa per un particolare diagramma. Questa soppressione può succedere o generalmente –

nascosti tutti gli attributi – o specificamente – non mostra queste tre classi. In un diagramma, quindi, tu non puoi

dedurre qualcosa dalla sua assenza. Se una varietà sta fallendo, tu non puoi dedurre quale importanza esso potrebbe

avere. Anche se l’UML meta-model ha una mancanza, come (1) per gli attributi, se tu non vedi l’informazione sul

diagramma, può essere per mancanza o perché è stata soppressa.

Avendo detto ciò, ci sono delle convenzioni generali, così come proprietà multivalori essendo complessi. Nel testo,

indicherò queste convenzioni mancanti.

E’ importante non mettere troppa enfasi nel rendere legale l’UML se tu sei uno skether o un blueprinter. È molto

importante avere un buon design per il tuo sistema e io vorrei piuttosto avere un buon design in un UML illegale che

uno legale ma povero design. Chiaramente, buono e legale è meglio, ma tu stai meglio mettendo la tua energia

nell’avere un buon design che preoccupato su un arcano (falso) dell’UML. (Naturalmente, tu devi essere “fiscale”

nell’UML come linguaggio di programmazione, o il tuo programma non funzionerà correttamente!)

Il significato di uml

Una delle più delicate questioni sull’UML è che, anche se la specificazione descrive in gran dettaglio com’è l’UML ben

formato, non c’è molto da dire su quello che l’UML significa fuori del mondo rarefatto dell’UML meta-model. Non

esiste una definizione formale di come l’UML rappresenta (su carta) un particolare linguaggio di programmazione. Tu

non puoi vedere un diagramma UML e dire esattamente quale codice equivalente andrebbe meglio. Dunque, tu puoi

avere una brutta idea di quello che il codice sembrerebbe meglio. In pratica, quello è sufficiente per essere utile. I

gruppi di sviluppo spesso formano le loro locali convenzioni per questi, e ti sarà necessario essere familiare con quello

in uso.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK 5 INGEGNERIA DEL SOFTWARE - UML

UML non e’ sufficiente

Anche se l’UML fornisce piuttosto un corpo considerevole di vari diagrammi che aiutano a definire un’applicazione,

non comprende una lista completa di tutti gli utili diagrammi che tu potresti volere usare. In molti posti, differenti

diagrammi possono essere utili, e tu non esiteresti nell’usare un diagramma non-UML se il diagramma UML non

soddisfa i tuoi propositi.

Accorrerai in vari tipi di queste cose in vari libri. Non esitare di trovare fuori tecniche che sembrano appropriate per il

tuo progetto. Se essi lavorano bene, usali. Se no, scartali. (Questo è, naturalmente, lo stesso consiglio per i diagrammi

UML).

Da dove iniziare con l’uml

Nessuno, neanche i creatori dell’UML, capiscono o usano tutto di esso. Molta gente usa una piccola sottoserie di UML

e lavorano con quella. Tu devi trovare la sottoserie dell’UML che lavora per te e i tuoi colleghi.

Se tu sei avviato, ti suggerisco di concentrarti prima sulle forme base dei diagrammi di classe e i diagrammi a sequenza.

Queste sono le più comuni e, nel mio punto di vista, il più utile tipo di diagramma.

Non appena hai modo di cadere in questi, tu puoi iniziare usando alcune delle più progredite notazioni dei diagrammi di

classe e dare uno sguardo agli altri tipi di diagramma. Sperimenta con i diagrammi e vedi come sono utili per te. Non

essere spaventato nel lasciar perdere quelli che non sembrano essere utili per il tuo lavoro.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK 6 INGEGNERIA DEL SOFTWARE - UML

PROCESSO DI SVILUPPO

Come già menzionato, l'UML prese spunto da un insieme di metodi di progetto e di analisi 0bject 0riented. 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.

E' 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 le molte 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.

Aldilà 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, i

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


PAGINE

13

PESO

125.88 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Fondamenti di informatica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Fassolino Rita.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Fondamenti di informatica

Fondamenti di Informatica - von neumann e processore
Dispensa
Fondamenti di Informatica – Dispensa
Dispensa
Appunti di Fondamenti di Informatica
Appunto
Fondamenti di informatica - Esercitazioni
Esercitazione