Classe (informatica): differenze tra le versioni

 

== Le classi nell'analisi ''object-oriented'' ==

 

L'[[analisi dei requisiti]], o semplicemente ''analisi'', costituisce una delle prime fasi del [[ciclo di vita del software]], e precede almeno le fasi di [[progettazione (ingegneria del software)|progettazione]] e [[implementare|implementazione]]. Lo scopo di questa fase è comprendere, chiarire e documentare ''cosa'' il sistema software deve fare, ovvero quali sono le funzionalità che si richiede possieda; non ci si occupa invece di definire ''come'' siano realizzate queste funzionalità (se non, a un livello molto grossolano, per una [[analisi costi-benefici|stima approssimativa dei costi]]).

* il ''comportamento'' di quelle entità, in termini delle [[operazione (informatica)|operazioni]] che tali entità possono eseguire o che possono essere eseguite su di esse; per esempio, da un conto corrente si può prelevare denaro. Le operazioni vengono analizzate stabilendo (anche) in quale modo la loro applicazione modifica lo stato (il prelievo di denaro diminuisce l'entità del saldo).

 

 

Il [[modello]] del dominio che l'analisi va a definire può essere arricchito da una serie di informazioni aggiuntive che riguardano le relazioni fra le diverse classi identificate. Fra gli esempi solitamente più importanti di relazione si possono citare i seguenti:

 

* le [[associazione (informatica)|associazioni]] specificano relazioni fra le istanze delle classi; per esempio, il fatto che i conti correnti siano ''intestati a'' clienti della banca definisce un'associazione fra la classe ''conto corrente'' e la classe ''cliente'';

* le [[relazione ISA|relazioni ISA]] (relazione "è un") specificano che una classe deve considerarsi una ''sottocategoria'' o ''sottoclasse'' di un'altra (detta ''superclasse''); per esempio, la classe ''conto corrente'' potrebbe essere descritta come sottocategoria della classe ''servizio bancario''. Il nome della relazione segue dal fatto che si può sensatamente dire, per esempio, che un conto corrente ''è un'' ("is a", ISA) servizio bancario. Si noti che questa rappresenta una relazione esclusivamente fra classi e non fra istanze. La relazione ISA ha un ruolo importante nella razionalizzazione di un modello. Un aspetto fondamentale è che si può assumere che una sottoclasse sia sicuramente dotata di tutti gli attributi, le operazioni e le associazioni della superclasse; eventualmente può averne altre, legate alle particolarità specifiche della sottocategoria di oggetti che descrive. Per esempio, se un ''servizio bancario'' ha un costo annuo ed è intestato a un cliente, tutto ciò resta vero per un ''conto corrente''; quest'ultimo ha inoltre un ''saldo'', attributo che non ha necessariamente senso per tutti i servizi bancari (e che quindi non comparirà nella classe più generica ''servizio bancario'').

 

La [[progettazione orientata agli oggetti|progettazione object-oriented]] viene generalmente utilizzata nei casi in cui si prevede una implementazione anch'essa orientata agli oggetti, in un linguaggio opportuno come [[C++]] o [[Java (linguaggio)|Java]]. Questi linguaggi dispongono infatti di un concetto di ''classe'' (vedi sezione successiva) strutturalmente simile a quello utilizzato in fase di analisi. In tal caso, la progettazione consiste in un [[raffinamento]] e una estensione del modello prodotto dall'analisi. Questa trasformazione del modello avviene sulla base di due linee guida generali:

 

 

* le classi del modello risultante (sia quelle derivati dall'analisi che quelle legate all'architettura del sistema) vengono solitamente dettagliate introducendo informazioni aggiuntive che serviranno a guidare l'implementazione; per esempio, si stabiliscono i [[tipo di dato|tipi]] degli attributi e dei [[parametro (programmazione)|parametri]] delle operazioni. Si potrà stabilire, per esempio, che il saldo di un conto corrente sia un numero con la virgola, e analogamente l'operazione "preleva" richieda la specifica di un numero con la virgola che rappresenta la somma da prelevare.

Una delle caratteristiche fondamentali dell'approccio orientato agli oggetti è la maggiore "fluidità" (rispetto agli approcci precedenti, come quello [[programmazione procedurale|procedurale]]) con cui le fasi di analisi, progettazione e implementazione sfociano ciascuna nella successiva. Questa fluidità è dovuta al fatto che i [[linguaggio di programmazione|linguaggi]] [[programmazione orientata agli oggetti|orientati agli oggetti]] forniscono una serie di strumenti sintattici e semantici che sono la diretta trasposizione degli strumenti concettuali di cui si è parlato per quanto riguarda le fasi di analisi e progettazione.

 

 

Se da un punto di vista storico e tecnico la classe dei linguaggi orientati agli oggetti si può considerare come una evoluzione del [[Struttura dati#Record o struttura|record]] di linguaggi procedurali tipo [[linguaggio C|C]] o [[Pascal (linguaggio)|Pascal]], essa sottende un approccio completamente diverso alla programmazione, in cui i [[tipo di dato|tipi di dati]], corredati delle loro operazioni (metodi) diventano centrali. Gran parte delle novità significative di questo approccio sono legate ai concetti di [[ereditarietà]], [[information hiding]] e [[Polimorfismo (informatica)|polimorfismo]].