Newsgroup: it.comp.java
Titolo: Java teoria: convenzioni da usare durante la progettazione di una applicazione [OT ?]

Premessa
----------
La progettazione di una applicazione, come quella di un generico
dispositivo, sia esso elettronico, meccanico o di altra natura, coinvolge
numerose fasi fra cui lo studio di fattibilità ed il coinvolgimento del
cliente per l'approvazione di quanto l'analista ha interpretato dalle
specifiche fornite dal cliente stesso,
in modo verbale oppure secondo un capitolato di fornitura.
La mia specializzazione è nel campo elettronico quindi la programmazione (di
qualunque cosa sia un PC oppure un micro) è una passione. A tale proposito,
leggendo letteratura più orientata alla programmazione come, ad esempio, DEV
oppure Computer Programming spesso incontro diagrammi
relativi alla struttura astratta del progetto da realizzare. Esempi di
classi (raffigurate in rettangoli), e simboli come frecce che terminano in
rombi connessi ai rettangoli sopra accennati. In sostanza
un modo di descrivere il problema ad un livello di astrazione più alto del
codice che si potrà utilizzare
per eseguire il compito richiesto.
A tale proposito, scusate se sono stato troppo prolisso, mi piacerebbe
sapere dove poter reperire
dei documenti di riferimento sulla descrizione di un progetto in modo
astratto utilizzando la simbologia
grafica sopra accennata. Da qualche parte ho sentito parlare di UML, ma non
vorrei sbagliarmi oppure citare qualcosa di utilizzabile, ma troppo
complesso per quello a cui mi sto riferendo. In sostanza avrei bisogno di
riferimenti in grado di guidarmi nella costruzione di pseudo-flowchart che a
colpo d'occhio mi consentano di sapere le relazioni di parentela fra gli
oggetti, i legami fra le varie azioni e gli oggetti interessati da tali
azioni e cosi via
Spero di essere stato in grado di rendere l'idea ... e sopratutto di non
essere troppo OT.
Ciao
Pow
--
----------------------------------------------------
Ama il tuo mestiere con passione
E' il significato della tua vita
Auguste Rodin (1840-1917)
 "Not everything that  counts can be
 counted, and not everything that can
be counted counts".
Albert Einstein
"Hunt for the Engineer and the Engineer will hunt you."
Hellraiser5 Pinhead

 complesso per quello a cui mi sto riferendo.
Cercherò di essere il piu' breve possibile, per il resto la rete (e questo
NG) è piena zeppa di informazioni sull'argmento.
Quindi queste righe sono solo una breve introduzione.
Le specifiche e la progettazione possono essere condotti con metodi
informali, semi-formali o formali. Lasciamo perdere quelli informali perché
come puoi immaginare si basano principalmente sul linguaggio naturale.
UML è uno strumento per "modellare" la realtà oggetto del software sotto
molto aspetti. In generale cmq UML è un insieme di strumenti che permettono
di realizzare modelli semi-formali, in cui cioé, la sintassi è ben definita
(quale simbolo usare per cosa) mentre la semantica è quasi inesistente (Il
significato dipende da quanto azzeccate sono le scelte dei nomi ed i
commenti, per fartela mooolto breve ;).
Quello che a te serve di UML probabilmente è solo il "diagramma delle
classi" con cui realizzare la struttura del software prima di scrivere il
codice.
Ci sono poi anche i diagrammi degli Use Case (che sono parte di una
specifica basata su Use Case) che aiutano a chiarire cosa si aspetta
l'utente dal SW.
Anche su questo la rete è piena di informazioni.
Ci sono anche molti altri diagrammi che se ti interessano puoi guardare, ma
diciamo che il piu' utile per te, forse, in questo momento è il class
diagram.
Si puo' poi modellare il flusso di dati attraverso le varie parti
dell'applicazione, chiarendo chi li elaborerà e dove andranno a finire. I
DFD (Data Flow Diagram se non ricordo male) sono un esempio di questo tipo
di diagrammi. Anche loro sono un tipo di specifica semi-formale.
Puoi ancora modellare il comportamento che il software dovrà avere con
diagramma degli stati e delle transizioni (se ti intendi di elettronica
avrai ben presenti gli automi per il comportamento delle macchine
sequenziali).
Diciamo che casi d'uso (Use case diagram), struttura del SW (class diagram),
flusso dei dati (DFD), comportamento del sistema (Automa) dovrebbero
bastare per progettare un SW non eccessivamente complesso.
Arriviamo ora ai dati. 
Il modello E-R è, invece,un modello formale. Sintassi e semantica sono
completamente definiti. I contrutti sintattici sono in un certo senso
analoghi a quelli del class diagram UML e piu' in generale all'
Object-Orientation (un entità è concettualmente una classe... una relazione
è una associazione...). La semantica però è ben definita in termini di
relazioni matematiche e di operazioni su insiemi che non permettono di
"fraintendere" un diagramma.
Uno schema E-R è utilizzato nella progettazione delle basi di dati per
rappresentare appunto il dominio dei dati. Da quello si passa al "diagramma
E-R ristrutturato" e poi allo "schema logico" da cui si ottengono le
tabelle di un DB relazionale (basato, cioè, sul modello entità-relazione).
Divertiti!
Ciao
Matteo

 ha scritto nel messaggio
news:Jp4Fa.16709$Fr5.3...@tornado.fastwebnet.it...

Grazie per le info, se hai dei link da segnalarmi ben vengano, diversamente
inizio da Google.


 inizio da Google.
posso farti una piccola osservazione?
non è carino rispondere ad un messaggio con
una riga e riportare per intero il messaggio originale
non che io sia ligio alle regole ma ogni tanto bisogna ricordarlo
(purtroppo mi è capitato a tiro il tuo post :)
ciao]o
--
Andrea
http://jame.sf.net

 ha scritto nel
messaggio news:IG5Fa.74676$Ny5.2...@twister2.libero.it...

Infatti hai ragione, il fatto è che mi è scappato dato che lo avevo
preparato off-line e non avevo apportato i vari tagli.


 complesso per quello a cui mi sto riferendo.
Martin Flower, UML distilled. Non e' troppo complesso, ed e' quello a cui 
ti stai riferendo. Probabilmente c'e' anche tradotto.
-- 
Fighting for peace is like fucking for virginity
ObjectZone - 
http://space.tin.it/computer/csadun