Newsgroup: it.comp.lang.c++
Titolo: C++ e UML ...

... nella pratica vanno d'accordo?
Preciso meglio la domanda:
nella pratica gli ambienti (tipo il Borland Together) che integrano i 
vari linguaggi ad oggetti (C#, c++, java, delphi ...) con il linguaggio 
UML vengono utilizzati oppure sono relegati nell'ambito 
scolastico/universitario?
Eventualmente c'è qualche esempio di applicativo di una certa rilevanza 
cha ha il codice "descritto" interamente in UML?


Secondo me e' un approccio che non ha molto senso, sarebbe un po' come
andare in giro con una cartina in scala 1:1; di certo non manca un
dettaglio, ma quanto a praticita'...
Il problema a mio avviso e' usare il linguaggio di descrizione giusto
per il livello di astrazione che si sta esaminando. Se il livello di
astrazione e' quello del codice il linguaggio migliore e' quello con
cui il codice e' scritto e ripetere le stesse cose in un altro
linguaggio non ne rende piu' facile la comprensione.
Ciao,
Nicola

 cha ha il codice "descritto" interamente in UML?
http://www.uml.org/uml_success_stories/index.htm
Ciao,
Cesare

Cesare ha scritto:

argouml lo utilizzi come documentazione "scollegata" dal codice? ovvero
se modifichi il codice la documentazione si modifica automaticamente
oppure deve essere fatto manualmente l'aggiornamento?
ByBy e ... grazie mille!

 oppure deve essere fatto manualmente l'aggiornamento?
manualmente.
Argouml viene utilizzato solo per generare le figure dei grafici UML di 
documenti di design scritti con word.
Potrei benissimo usare visio o un plugin di word.
In pratica e` un tool che non entra mai nella catena di produzione del 
software.
Ovviamente quando si modifica il codice la documentazione non e` 
allineata automaticamente.
Alcune parti del progetto sono documentate con dei tool piu` leggeri: 
qualche parente di doxygen per interderci.
Non sto dicendo che sia questo l'utilizzo "comune" di questo genere di 
tool anzi sarei ben contento di leggere di qualcuno che usa 
produttivamente questi cosi nel quotidiano. Io, in pratica, non li uso.
Comunque ho dei dubbi che un unico tool possa gestire dei progetti 
grossi e complessi e tenere allineati codice e documentazione.
Tu dirai... non capisco fammi un esempio.
Supponi che sei su un progetto in cui si usa un sistema operativo 
realtime. In questo caso il sistema operativo lo compri ed inoltre tutto 
il codice del sistema operativo entra diventa parte della tua 
applicazione. Ma qui nascono i problemi: ad esempio non hai il codice 
del sistema oerativo perche` non hai comprato i sorgenti, oppure anche 
se compri i sorgenti sicuramente non puoi imporre ad un vendor di RTOS 
che il suo codice sia conforme all'uso del tool UML che hai scelto.
Supponi poi che la tua applicazione debba comunicare tramite CORBA con 
qualche con un altro software... chesso` un gestore di rete.
Cosa fai ti scrivi da zero un ORB CORBA?
No, si compra e si integra nel tuo progetto. E il codice o libreria 
dell'ORB che hai comprato e` conforme al tool UML che hai deciso di 
usare? No.
Queste sono le situazioni con cui ci si scontra in questo genere di 
progetti. Non so se ho reso l'idea.
Ovviamente questi sono solo problemi tecnici.
Nel mondo reale poi ci sono anche quelli di budget, di management, di 
politica, filosofia, tutte cose molto off topic.
Ciao,
Cesare

 progetti. Non so se ho reso l'idea.
Sě, hai reso l'idea ...
... ma nel caso uno deve sviluppare un applicativo basandosi solo sugli 
strumenti e librerie che gli offre l'ambiente di sviluppo (per fare un 
esempio delphi/c++Builder) secondo te puň č un'impresa impossbile voler 
utilizzare in parallelo anche il linguaggio UML?
Per la mia esperienza in ambito "Programmazione a finestre" ho visto 
comunque progetti, che sebbene "semplici" dal tuo punto di vista 
(sviuluppati all'interno di un unico ambiente di sviluppo), comunque per 
manutenerli non era cosě facile e quindi ora mi chiedo se č possibile 
almeno nei progetti "semplici" avere un fruttuso utilizzo degli 
strumenti uml sia come documentazione ma anche e specialmente come 
manutenzione.


 standard?
Sul fatto che venga automatico fare degli schemi non sono cosi'
convinto, per certe cose si per altre no. Sul fatto di usare un
linguaggio standard sono d'accordo, ma non e' detto che sia sempre UML.
Se devo scrivere un analizzatore lessicale magari disegnero' un
diagramma, ma sara' molto piu' facilmente un diagramma a stati
tradizionale che non un diagramma statechart UML. Figurarsi poi se
lavoro su database, dove i diagrammi E-R esistono e sono ben piu'
standard di qualsiasi cosa offra UML.
Ciao,
Nicola

 manutenerli non era così facile e quindi ora mi chiedo se è possibile


 manutenzione.
Su dei progetti piccoli autocontenuti puo` essere forse utile usare uno 
di questi tool (together, rational rose ecc.).
Ma non si puo` mai essere sicuri che in un progetto non entri mai del 
codice "esterno" alle librerie supportate dal tool.
Secondo me seguire tutto il ciclo di vita di un SW sviluppato da un team 
con questi tool puo` diventare veramente oneroso a meno di non 
velocizzare tanto la fase di design, che e` proprio quella che questi 
tool "promettono" di velocizzare.
Secondo me e` piu` produttivo usare delle tecniche nel ciclo del SW che 
hanno un provata efficacia nel lavoro in team, piuttosto che affidarsi 
ad un tool.
Esempio:
- Uso di tecniche di design se applicabili (esempio: design patterns).
- Inserire la documentazione nel codice con commenti e uso di tool alla 
"doxygen".
- Indentazione del codice controllata tramite tool indentatori.
- Uso di tool di analisi statica (lint).
- Introduzione delle code review nel team.
- Controllo del codice prodotto tramite unit test (es. agile programming).
L'uso di queste tecniche puo` aiutare molto a produrre un ciclo di vita 
del SW efficiente dal design alla manutenzione. L'introduzione di tutto 
questo ha un costo che va` valutato in base a quanto migliora la 
qualita` del codice.
Ciao,
Cesare