Anteprima
Vedrai una selezione di 14 pagine su 62
Lezioni, Ingegneria del software Pag. 1 Lezioni, Ingegneria del software Pag. 2
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 6
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 11
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 16
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 21
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 26
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 31
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 36
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 41
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 46
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 51
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 56
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 61
1 su 62
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

RADUZIONE

A seconda della cardinalità delle relazioni, vi saranno vari tipi di traduzione da modello concettuale a

modello logico.

5.5.1 Traduzione molti a molti

5.5.2 Traduzione uno a molti

5.5.3 Traduzione uno a uno

5.5.3.1 (1,1) – (1,1)

5.5.3.2 (0,1) – (1,1)

5.5.3.3 (0,1) – (0,1)

6 A

UTOMI A STATI FINITI

Un automa è un modello formale che descrive gli stati in cui il sistema può trovarsi durante la sua

evoluzione. Ve ne sono diversi tipi:

 Automa di Mealy: L’uscita è associata alle transizioni che portano il sistema nel nuovo stato.

 Automa di Moore: La risposta dipende dallo stato stesso, non da come è stato raggiunto.

 Automa deterministico: Se lo stato successivo è univocamente determinato.

 Automa non deterministico: Se lo stato successivo non è univocamente determinato.

Un automa a stati finiti è un automa definito dalla sestupla:

 S: Insieme degli stati

 I: Insieme degli ingressi

 U: Insieme delle uscite

 d: Funzione di trasformazione

 t: Funzione di uscita

 s₀: Stato iniziale

Un automa a stati finiti può essere rappresentato anche da un grafo orientato.

6.1 A

UTOMI IN SISTEMI CONCORRENTI

Gli automi a stati finiti possono essere anche utilizzati per rappresentare delle cooperazioni tra diverse

attività quando operano in modo concorrente.

Ad esempio:

6.2 P

RO E CONTRO

6.2.1 Pro:

Il modello è orientato alla specifica del controllo. La notazione è adatta per sistemi con pochi stati

6.2.2 Contro:

Il concetto di stato è trattato in maniera globale, inoltre è un modello troppo semplice per gestire sistemi

complessi. Non vi è poi la possibilità di specificare condizioni sulle transizioni.

7 M

ODELLAZIONE A OGGETTI

7.1 O

RGANIZZAZIONE IN MODULI

Nella progettazione di un sistema software assume grande importanza il concetto di modularità.

Un modulo è una parte del sistema che realizza un’astrazione.

I meccanismi più comuni di astrazione sono:

 Astrazione sui dati

 Astrazione sul controllo

7.1.1 Astrazione sul controllo

Astrae una funzionalità dai dettagli dell’implementazione.

È supportata dai linguaggi di programmazione tradizionali tramite il concetto di sottoprogramma.

7.1.2 Astrazione sui dati

Astrae le entità, come gli oggetti, descritte in termini di una struttura dati e delle operazioni possibili su di

essa. Questo è il concetto alla base della modellazione a oggetti.

È supportata da appositi costrutti nei linguaggi di programmazione a oggetti.

Rispetto alle funzioni, gli oggetti (astrazione sui dati), hanno una struttura dati permanente, visibile tramite

funzioni interne.

7.1.3 Tipo di dato astratto

Il tipo di un linguaggio di programmazione è un insieme di valori che può assumere un dato.

Il tipo di dato astratto estende questo concetto, includendo anche tutto l’insieme di operazioni possibili su

quel tipo di dato.

Si dice infatti, che la struttura dati vera e propria, è incapsulata nelle operazioni su essa definite. Con ciò si

intende che è possibile accedervi solo tramite le proprie operazioni.

Il grande vantaggio di questo metodo di astrazione, è che la struttura dati interna non può essere

modificata in modo sbagliato dall’utente, in quanto egli può accedervi solo tramite delle operazioni

precedentemente stabilite dal produttore, che si presume siano funzionanti.

7.1.3.1 L’interfaccia

È una specifica del tipo di dato astratto, descrive la parte direttamente accessibile dall’utilizzatore.

L’utilizzatore infatti, accede a funzioni che sono state rese disponibili dal produttore, senza sapere come

sono implementate, ma non gli interessa, perché ciò non inficia il risultato.

7.2 L

A MODELLAZIONE AD OGGETTI

Si individuano le classi di oggetti (Nella realtà concettuale) che caratterizzano il dominio di applicazione.

Ogni classe è descritta da un’interfaccia che specifica il comportamento degli oggetti.

7.2.1 Programmazione ad oggetti

A livello di implementazione distinguiamo:

 Programmazione con oggetti: tecniche basate sul concetto di oggetto (dati + operazioni).

 Programmazione basata sugli oggetti: tecniche basate su:

- Classi

- Oggetti

 Programmazione orientata agli oggetti: Tecnica che include

- Classi

- Oggetti

- Ereditarietà

- Polimorfismo

Esistono due tipi di linguaggi ad oggetti:

 Non tipizzati: Permettono di definire oggetti senza dichiarare il loro tipo

 Tipizzati: Permettono la definizione di tipi di dati astratti, e di istanziarli. Qui la classe è

un’implementazione di un tipo di dato astratto, l’oggetto è l’istanza di una classe.

7.2.2 Le classi

7.2.2.1 In fase di analisi

La classe è in questa fase una vista concettuale del problema. Cattura i concetti principali del dominio

svincolandosi completamente da come saranno rappresentati dal software.

Rappresenta “cosa” il sistema farà, non “come”.

7.2.2.2 In fase di progettazione

La classe indica quali saranno le interfacce del sistema.

La classe è dotata di:

 Interfaccia: specifica

 Corpo: implementazione

Se l’interfaccia non cambia, è possibile modificare il corpo senza che questa modifica vada a influenzare le

altre parti del software. Questo rende più semplici le modifiche.

7.2.2.3 In fase di implementazione

La classe e le relazioni indicano la reale struttura del software.

È qui che diventa un’implementazione di un tipo di dato astratto.

7.2.3 L’utilizzo di una classe

L’uso delle classi è orientato alla riusabilità del software.

Il produttore della classe mette a punto:

 La specifica (Header file)

 L’implementazione (File .cpp)

L’utilizzatore invece ha a disposizione la specifica della classe e può creare oggetti istanziandola.

7.2.4 Le classi in C++

Il linguaggio C++ supporta esplicitamente le classi tramite il costrutto class.

Le istanze di una classe sono dette oggetti.

La classe possiede:

 Una sezione pubblica: contiene le operazioni consentite agli utilizzatori

 Una sezione privata: contiene le strutture dati e le operazioni da rendere inaccessibili dall’esterno

7.3 E

REDITARIETÀ

Induce una strutturazione gerarchica nel sistema software.

Permette di realizzare relazioni tra classi del tipo generalizzazione – specializzazione.

Vi sono infatti:

 Classe base: Realizza un comportamento comune ad un insieme di entità

 Classe derivata: Realizzano comportamenti specializzati rispetto alla classe base

Es: Classe base: Animale. Classe derivata: Gatto

Le classi derivate sono specializzazioni, ossia casi particolari, della classe base.

 Generalizzazione: Passa dal particolare al generale

 Specializzazione: Passa dal generale al particolare

È utile anche per il riuso del software, in quanto a volte si ha a disposizione una classe che ha a disposizione

solo alcune caratteristiche tra quelle che abbiamo bisogno. Invece di riscrivere completamente la classe,

creiamo una gerarchia, con la classe derivata che avrà tutte le caratteristiche della classe base, con in più

quelle mancanti che aggiungeremo successivamente.

Favorisce riuso, manutenibilità ed incrementalità.

7.4 P

OLIMORFISMO

È una proprietà di un’entità di assumere forme diverse nel tempo.

Un’entità è polimorfa se può fare riferimento, nel tempo, a classi diverse.

Supporta la proprietà di estensibilità di un sistema, minimizza la quantità di codice da modificare quado si

introducono nuove classi e funzionalità.

Il polimorfismo viene realizzato tramite il binding dinamico.

Il binding dinamico, o late binding, determina a tempo d’esecuzione, il corpo del metodo da invocare su un

dato oggetto.

7.5 I VANTAGGI DELLA MODELLAZIONE A OGGETTI

 Modularità: Le classi sono i moduli del sistema software.

 Coesione dei moduli: Una classe è un componente ben coeso perché rappresenta un’unica entità.

 Disaccoppiamento dei moduli: I moduli sono ben disaccoppiati perché i loro metodi operano sulla

struttura dati interna ad un oggetto

 Information hiding: Strutture dati e algoritmi sono nascosti all’esterno.

 Riuso: L’ereditarietà consente di riusare la definizione di una classe per definire nuove sottoclassi

 Estensibilità: Il polimorfismo agevola l’aggiunta di nuove funzionalità, minimizzando le modifiche

necessarie al sistema quando lo si vuole estendere.

8 UML: A

SPETTI STATICI

L’UML è un linguaggio universale utilizzabile per specificare, progettare e rappresentare un sistema, non

solo software. Per questo non è un linguaggio di programmazione.

Nel 1997 è diventato uno standard OMG (Object Management Group).

Più che un linguaggio di programmazione, l’UML è un meta-modello, cioè un linguaggio per specificare

modelli.

8.1 I UML

DIAGRAMMI

Ogni diagramma è progettato per fornire la vista del sistema software da diverse prospettive.

I diagrammi si dividono in:

 Diagrammi comportamentali: Casi d’uso, classi, sequenza, collaborazione, stato, attività.

 Diagrammi di implementazione: Componenti, distribuzione.

8.2 I ’

L DIAGRAMMA DEI CASI D USO

Un caso d’uso è un’interazione tra un utente ed il sistema.

Permette la rappresentazione delle funzionalità esterne, individuare ruoli e processi.

Ha lo scopo di catturare le funzionalità del sistema così come percepite dall’utente.

Ragionare sui casi d’uso, aiuta a scoprire i requisiti del sistema tramite successivi raffinamenti.

I casi d’uso possono essere in relazione tra di loro. Le relazioni che possono avere sono di tipo:

 Include: Un caso d’uso ne include un altro, senza il quale non può funzionare.

 Extends: Un caso d’uso è esteso da un altro caso d’uso, che ne rappresenta l’alternativa.

8.2.1 Attore

È un soggetto esterno al sistema.

Un attore può essere:

 Una classe di persone

 Un altro sistema software

 Un dispositivo hardware esterno

 Il tempo

L’attore interagisce con il sistema, fornendo uno stimolo e ricevendo un output.

8.2.2 Relazione di inclusione

Un comportamento comune a più casi d’uso, diventa un caso d’uso che è incluso nei casi d’uso di partenza.

Il caso d’uso incluso non ha senso da solo.

8.2.3 Relazione di estensione

Si usa quando una sequenza opzionale

Dettagli
Publisher
A.A. 2014-2015
62 pagine
1 download
SSD Ingegneria industriale e dell'informazione ING-INF/05 Sistemi di elaborazione delle informazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher KekkoV94 di informazioni apprese con la frequenza delle lezioni di Ingegneria del Software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli studi di Napoli Federico II o del prof Russo Stefano.