Newsgroup: it.comp.lang.c++
Titolo: Progettate con OMT o a sentimento?

Il C++ impone disciplina al programmatore (più del C liscio), ma
questa da sola può non essere sufficiente per costruire da zero un
progetto di medie dimensioni.
Ho studiato il metodo OMT per il corso di Basi di dati, e lo trovo
veramente potente se applicato ai DBMS ad oggetti, ma mi chiedo se
qualcuno lo usa anche nella programmazione "ordinaria": non è come
usare un carrarmato per uccidere una mosca?
Con meno di 10/20 classi mi pare così, ma avete un'esperienza diversa?
In definitiva vorrei sapere come costruite il vostro programma ad
oggetti, e magari quale è il sistema che mi consigliate di adottare e
che a voi ha dato tanti benefici.
Aspetto le risposte su questo NG.
Grazie,
Athos.

che a voi ha dato tanti benefici.
UML e` bello perche` e` molto flessibile -- un "linguaggio"
grafico standardizzato per esprimere concetti di analisi e
soprattutto di progettazione.  Nessuno ti obbliga a fare un
dato diagramma dei tanti che UML prevede -- lo farai se
ed in quanto vedi che il tuo sistema puo` avere dei problemi
di organizzazione da quel certo punto di vista.
Alex

Volevo aggiungere alcune altre considerazioni legate all'eventuale
utilizzo o meno di una metodologia nello sviluppo di applicazioni ad
oggetti (non ha importanza il linguaggio utilizzato) anche piccole.
E' importante cercare di applicare una metodologia (OMT, Booch, OMT+,
Objectory...) a qualsiasi tipo di progetto, anche a quelli piccoli in
quanto l'utilizzo della stessa permette di sviluppare un approccio
corretto alla progettazione del software.
Ad esempio, tutte le metodologie indicano quali sistemi utilizzare per
identificare le classi (oggetti) di partenza (molto spesso non
corrispondono a quelle finali) a partire dalle specifiche (anche da
specifiche semplici magari scritte su un tovagliolino mentre si sta
mangiando un panino). Da queste classi, combinando l'analisi della
dinamica del sistema a quella statica - e' piu' semplice a dirsi che a
farsi - si arriva a definire nuove classi, ad eliminarne alcune e a
strutturare (brutta parola) le relazioni (messaggi) tra le stesse
classi.
Nelle diverse metodologie sono presentati varie tecniche di analisi,
progettazione e sviluppo di programmi ad oggetti. Anche se molto spesso
queste metodologie sono rivolte a problemi complessi gli esempi
riportati sono piu' spesso di dimensioni ridotte (10/20/30 classi) che
permettono a chiunque di seguire il modello ed applicarlo alla propria
applicazione.
Inoltre, sono presenti alcune metodologie semplificate (ridotte da
quelle principali) e specificamente rivolte a chi vuole applicare una
metodologia per la prima volta, magari ad un progetto di piccole
dimensioni - come e' spesso consigliato, senza per questo allontanarsi
troppo da quelle che sono le metodologie dei guru della progettazione ad
oggetti.
Sono personalmente convinto, anche per esperienza personale e delle
persone con cui lavoro, che l'applicazione delle metodologie di cui
sopra anche a progetti di piccole dimensioni fornisca una base sicura
per la crescita futura sia di qualsiasi progetto (corretto sviluppo dei
principi della riutilizzabilita' del codice) che del
programmatore/progettista. Sicuramente, lo scopo di chiunque sviluppi
applicazioni software e' di arrivare prima o poi a sviluppare
applicazioni commerciali e in questo caso l'aver acquisito le
metodologie di cui sopra non puo' che essere un notevole punto a favore.
massimo