Newsgroup: it.comp.lang.c++
Titolo: Aiuto c++(per esame)

Per fare un esame all'università devo sviluppare  un elaborato in linguaggio
C++, consistente in un semplice simulatore di un processore. Il programma
deve simulare il caricamento da un file di un programma in un linguaggio
macchina molto semplificato, e la sua successiva esecuzione da parte della
CPU, mediante simulazione delle unità del modello di Von Neumann e visto che
è da poco che studio c++ non riesco a farlo.
Un ringraziamento a tutti quelli che mi aiuteranno
Pax

Mi pare eccessivamente generica (e comunque eccessiva) come
richiesta... prova ad affrontare il problema scomponendolo in
sottoproblemi:
Caricamento del programma
Eventuali operazioni di inizializzazione
Esecuzione
eventualmente scomponi ulteriormente sottoproblemi
difficili (es. esecuzione).
Se c'e` qualcosa che non riesci a capire, puoi chiedere
aiuto, ma non pretendere che ti si risolva il problema...
e` giusto chiedere dei suggerimenti (dritte) non il programma
bello e pronto.
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

difficili (es. esecuzione).
Perdonami, il mio non vuole essere un commento polemico ma solo una
richiesta di delucidazioni:
capisco che questo è il modo più adatto per affrontare un problema
complesso, ma lo scomporre il problema come dici tu, non porta ad un
programma procedurale più che ad oggetti? L'analisi di un problema che
dovrà essere modellato in C++ non dovrebbe essere svolta in un altro
modo?
GRAZIE
Daniele

...

Più che in altro modo credo che si debbano fare ulteriori valutazioni e
studi su quello che si vuole realizzare (le mie non voglio essere
affermazioni, ma solo opinioni di chi sta cercando di affrontare questi
argomenti, quindi correggetemi se sbaglio grazie) per realizzare un buon
programma OO bisogna innanzitutto ricavare dei casi d'uso e su questi
lavorare modellando poi le varie classi (andando sempre + nel dettaglio)
applicando i costrutti che il c++ (come altri linguaggi OO) ci permette di
utilizzare come il polimorfismo ereditarieta ed incapsulamento.
Non bisogna mai dimenticarsi che realizzare una "buona" analisi OO richiede
un grosso sforzo e costo, che sicuramente verrà poi ripagato, ma non sempre
è facile arrivarci. Quindi credo che il consiglio dato sia sempre valido
anche per un programma ad oggetti, sta poi a chi implementa il tutto
valutare se realizzare una analisi completa e ben fatta lavoro che cmq potrà
trarre beneficio da una preliminare scomposizione del problema.
Ciao
Terenzio

modo?
Sebbene possa apparire un procedimento apparentemente procedurale,
la tecnica divide et impera non e` in generale in contrasto con la OOP e`
un modo (tra tanti) di "ridurre" la complessita` di un problema
(Anzi... la OOP in fondo fa proprio questo).
Dato un certo problema, puoi decidere di affrontarlo direttamente cercando
di individuare le entita` dell'universo del discorso e capire come farle interagire
per risolvere il problema. In alternativa puoi scomporre il problema in sottoproblemi
e risolvere ad uno ad uno questi (come descritto prima) e poi combinare i
risultati.
Es.
Supponi di voler realizzare un programma di cad...
Che cosa deve fare il programma? Ottenere l'input, elaborarlo
e quindi visualizzare i risultati. 3 sottoproblemi che puoi affrontare
singolarmente dopo aver capito in quali relazioni stanno e
come combinare le rispettive soluzioni.
Puo` darsi che i sottoproblemi non siano totalmente disgiunti e
in tal caso dovrai individuare le parti comuni...
Spero di essere stato chiaro.


Paolo
Grazie della risposta.
Io non ho una grande esperienza, soprattutto della fase di analisi di
un progetto. Però ho letto gli articoli di C. Pescio di un po' di
tempo fa riguardo all'analisi e al progetto di sistemi ad oggetti
(disponibili anche sulla sua home page). 
Beh, negli articoli sull'analisi si agiva in un modo completamente
diverso a quello che proponi tu (è per questo che ho fatto la domanda
iniziale...): si diceva infatti di partire dalla descrizione del
problema (che non doveva assolutamente contenere informazioni di
design) e da questo cercare gli oggetti che facevano parte del
problema. 
In effetti facendo l'analisi come tu suggerisci si ottengono delle
funzioni (nel tuo caso ad es.: Inizializza(), OttieniInput(),
Elaborazione() etc...) ma non degli oggetti in cui inserirle. 
Mi farebbe piacere sentire la vostra idea su come dovrebbe essere
svolta l'analisi di un problema la cui soluzione debba essere
implementata ad oggetti (mi farebbe anche piacere se deste un'occhiata
agli articoli di C. Pescio che citavo prima, per averne una vostra
opinione.)
GRAZIE
Daniele.


Probabilmente mi sono spiegato male...
In generale in applicazioni medio-piccole puoi
benissimo partire cercando di individuare le entita`,
tuttavia questo non e` sempre banale. Ad esempio
se dovessimo realizzare un sistema operativo, avrebbe
poco senso cercare subito le entita`, sarebbe meglio
cercare di capire quali compiti il programma deve assolvere
sperando di individuare una suddivisione verticale dei compiti
(gestione dei processi e dei processori, gestione della memoria,
gestione dell'I/O...) e quindi all'interno di ciascuna categoria
individuare le entita`.
Ad esempio in ogni applicazione GUI c'e` sempre l'interfaccia
e un "motore" che sta sotto l'interfaccia... in generale non
sarebbe corretto avere un oggetto che svolge sia il ruolo di
finestra che compiti di calcolo (e quindi a meta` tra i 2 livelli).
Una prima suddivisione alla divide et impera non significa
quindi risolvere la cosa cercando procedure, ma solo
decomposizioni astratte del problema a cui poi applicare
la tecnica di design desiderata.
Paolo


In generale in applicazioni medio-piccole puoi
[snip]
OK, adesso ho capito cosa intendevi. Sono d'accordo con te.
Scusa per l'equivoco.
Daniele.