Sviluppo software & UML

Forum dedicato alla programmazione.

Moderatore: Staff

Regole del forum
1) Citare in modo preciso il linguaggio di programmazione usato.
2) Se possibile portare un esempio del risultato atteso.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
tgmx
Linux 4.x
Linux 4.x
Messaggi: 1336
Iscritto il: ven 28 apr 2006, 14:40
Slackware: 14.1
Desktop: KDE 4
Località: Ancona

Sviluppo software & UML

Messaggio da tgmx »

Ciao Ragazzi,
scrivo questo post per discutere con chi ne ha voglia di come è meglio sviluppare un'applicazione (software).

Io lavoro in una piccola azienda nel ruolo di sviluppatore software (unico) in C++/QT .
Di solito non c'è mai abbastanza tempo per mettersi giù con carta e penna per analizzare a fondo il problema da affrontare quindi mi ritrovo a "buttare giù" le prime righe di codice e magari la prima bozza di interfaccia procedendo poi per affinamenti successivi. Tutto va bene fino a quando qualcuno ti viene a dire che bisognava aggiungere questa o quella funzione e ti accorgi di non poterlo più fare a meno di non riscrivere metà delle righe di codice già scritte...
Questo metodo sicuramente è sconsigliato ma spesso cambiano molto le cose passando dalla teoria accademica alla pratica... :D

Di questi tempi però si fa un gran parlare di UML o comuque sembra sempre più di moda come ausilio alla progettazione software quindi mi sono incuriosito e vorrei capirci di più.
So che sulla nostra Slack c'è "umbrello" che come descrizione ha "UML modeller" :) ma non ho ancora capito molto bene come utilizzarlo.

Voi come procedete per sviluppare le vostre applicazioni... ?

Avatar utente
lennynero
Linux 3.x
Linux 3.x
Messaggi: 641
Iscritto il: lun 3 mag 2004, 0:00
Nome Cognome: Luigi Picaro
Slackware: 15.0-x64
Kernel: 6.1
Desktop: Xfce-4.16
Località: Salerno

Re: Sviluppo software & UML

Messaggio da lennynero »

Argomento interessante, anche io mi sono spesso chiesto quale era il modo migliore per procedere allo sviluppo serio di applicazioni medio-grandi, e per la cronaca spesso la prerogativa principale è: sviluppare da solo, o meglio ancora, con poche persone molto capaci..., la mia regola è: se una serie di operazioni la devi ripetere 2 volte allora fai una procedura, questo nei linguaggi oo è abbastanza topico, infatti l'ereditarietà e il polimorfismo permettono di creare design pattern molto efficienti. Detto questo, io ho sviluppato software per lo + a livello accademico, lì malgrado tutto mi hanno detto(non insegnato) che bisogna prima progettare, e poi implementare; questo concetto può sembrare banale, ma è allo stesso tempo tedioso e spesso si pensa di poterne fare a meno, Purtroppo, o meglio, per fortuna la progettazione ha i suoi vantaggi in termini di flessibilità e di manutenibilità del codice. La prima cosa per un progettista/sviluppatore è utilizzare un ambiente di sviluppo consono, io uso Eclipse da molto tempo e penso sia il migliore in circolazione, meglio di quello c'è solo l'editor di testi. Per creare diagrammi UML in Eclipse esistono diversi plugin, addirittura sono in grado, ma questa è una cosa che ritengo vada trattata con molta cautela, magari per creare degli stubs, di generare codice a partire dai diagrammi progettati. Nel mio ultimo progetto, questa volta lavorativo, ho iniziato ad usare UML in reverse engineering, per generare i diagrammi a partire dal MIO codice, per me è stato innanzitutto un esercizio di stile, ma a suo modo può essere un buon supporto alla rappresentazione in uno pseudo-codice + descrittivo dell'implementatazione del progetto, può servire sia allo sviluppatore per avere qualche feedback riguardo l'architettura implementativa creata, sia per dare al cliente una vista comprensibile del lavoro svolto. Di plugin da poter usare ce ne sono una miriade sul sito: http://www.eclipseplugincentral.com/, per quanto riguarda il reverse io ho provato topcased.java.reverse, per creare un file .uml, poi ho utilizzato UML2 per generare i class diagram(ha uno scoping molto ristretto, infatti per avere una buona resa delle relazioni tra le classi è necessario che si trovino tutte nello stesso package), sto testando qualche altro tool ma purtroppo, e mi duole dirlo, sembra che i migliori siano i plugin commerciali (eUML Studio genera anche i sequence diagram....), inoltre esistono degli IDE Eclipse Based che integrano il supporto all'UML, vedi OMONDO e altri, ma l'approccio monolitico non mi piace.
Spero che qualcuno + esperto ci possa aprire la mente con qualche buon consiglio e le proprie esperienze sul campo.

Avatar utente
kreen
Linux 2.x
Linux 2.x
Messaggi: 228
Iscritto il: mer 1 feb 2006, 18:32
Slackware: 12.0
Kernel: 2.6.21.5-smp
Desktop: KDE
Località: Verona

Re: Sviluppo software & UML

Messaggio da kreen »

Anch'io come Lenny ho usato UML per il reverse Engineering di un'applicazione sviluppata con Flex 3.0 da un'altra persona ed è stato un aiuto pesante. Inoltre, se dovessi riprendere in mano l'applicazione (come dovrebbe essere, fra qualche mese) avrò già in mano un supporto efficace alla mia scarsa memoria.

Lasciando il caso specifico, programmo da veramente tanti anni, all'università ho imparato l'importanza della progettazione e che il codice è solo uno degli ultimi anelli della catena. All'inizio della mia carriera di programmatore aprivo l'editor di testo e iniziavo a scrivere.
Siccome avevo fretta di vedere dell'output, manco mettevo i commenti.
Nel proseguo, la mia esperienza mi ha portato a pensare che la ragione di tanto software scadente e pieno di bug che c'e' in giro dipenda appunto dal fatto che la teoria si discosta molto dalla pratica. I costi e i tempi portano a saltare parti importanti del processo di sviluppo.
Penso che un discorso del genere possa paradossalmente essere affrontato solo nel software libero. Ovvero, un team di persone che lavora ad un progetto e che non costa 50 euro all'ora, per sparare una cifra e che quindi possa fare le cose con calma e fatte bene.
Tieni conto che se le cose fossero fatte bene, Tizio potrebbe unirsi al team in qualunque momento e allinearsi in poco tempo, veramente poco.
Fatte bene significa utilizzando l'ingegneria del software, che è tutt'altro che banale e facile da affrontare e che fornisce tutti gli strumenti necessari a mantenere un progetto consistente. Aiuta a mantenere il treno nei binari.

Se tutto fosse "alla smanettona" Tizio ci metterebbe 10 volte tanto. L'ho provato sulla mia pelle e quindi so cosa vuol dire.
Ho lavorato sei mesi per un team di sviluppo all'università e ho visto che anche li', dove ci sono delle vere "menti" (te lo posso assicurare), si scade proprio sulle cose che invece dovrebbero essere distintive.
Per fare un esempio, il sistema che usano per tenere traccia dei bug, non viene mai aggiornato. Non si capisce una mazza: i bug sono o non sono ancora presenti? Una delle cose che mi avevano appunto detto di fare è riprovare tutti i test bench relativi ad una parte di progetto per vedere se c'erano ancora i bug...
La documentazione è pressoché inesistente. Il traduttore su cui stavo lavorando era veramente poco documentato. La differenza ad esempio che c'era con documentazioni tipo quelle di SUN per Java era abissale e l'ho fatto presente più di una volta. Ma le Milestone imposte dai partner e dalla comunità europea, non permettevano di dedicare più di tanto tempo alla stesura di una vera documentazione, quindi gli sfigati come me che arrivavano a fine progetto non ci capivano un tubo (immaginati di navigare tra decine di migliaia di righe di codice C dedicato a tradurre il SystemC in un altro linguaggio: un incubo).
Per farla breve, pensi che io abbia trovato un qualche "progetto" come si raccomanda in ingegneria del software? Naaaaahhhh.
Documento delle specifiche, dei requisiti, diagrammi di classe etc??? Ma dove???

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2922
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 15.0
Kernel: 5.15.19
Desktop: KDE5
Località: Bulagna
Contatta:

Re: Sviluppo software & UML

Messaggio da 414N »

Ho seguito due corsi di ingegneria del software (uno alla laurea triennale e uno alla specialistica) e, soprattutto l'ultimo, mi ha aperto nuovi orizzonti.
Nonostante concordi con molte cose già dette nel thread, mi preme sottolineare una questione: UML è uno strumento per modellare una qualsiasi realtà (anche se ancora troppo spinto agli oggetti, snaturando varie situazioni non propriamente object-oriented) e il fatto di usarlo tramite reverse engineering su codice già esistente è segnale di un processo di sviluppo del software non ottimale.
Mi spiego meglio: i modelli UML dovrebbero essere usati a priori nel processo di sviluppo di un software per rappresentare formalmente le varie entità in gioco nel progetto, fino a specificarne la struttura, l'interazione ed il comportamento. Terminata questa prima fase di analisi, si comincia a vedere come la teoria appena prodotta possa venire trasformata in pratica, iniziando il processo di implementazione/sviluppo. Questa fase, che NON è ancora prettamente quella di scrittura del codice, determina come quello che si è stabilito in analisi debba essere trasformato per adeguarsi ai costrutti del linguaggio/dei linguaggi scelti per l'implementazione (se scelgo di programmare in Java, avrò un supporto diverso da quello fornito dal C). In soldoni, si prendono i modelli prodotti durante l'analisi e si trasformano per adeguarli alle esigenze di implementazione, spesso rendendoli molto più dettagliati e dipendenti dalle scelte implementative.
Tramite l'uso di trasformazioni M2M (Model to Model) e DSL (Domain Specific Language), è poi possibile arrivare in un certo numero di passi alla generazione automatica della quasi interezza del codice necessario (non solo stub). Le parti non generate andranno poi integrate a mano, ma dovrebbero essere comunque una piccola percentuale.
Ora, tornando al discorso del reverse engineering, se uno genera i diagrammi UML a partire da codice scritto da terzi, avrà un diagramma delle classi (e spesso solo quello, mentre UML ha molti altri tipi di diagrammi) enorme e pieno di dettagli implementativi, che distolgono l'attenzione dal capire il funzionamento generale dell'accricco. Invece, in un processo di sviluppo del software più professionale, sarebbe bastato dare un'occhiata al diagramma dei package per avere un'idea del funzionamento generale del programma, delle entità principali in gioco e delle interazioni che intercorrono tra le sue componenti. E qui emerge un'altra caratteristica importante di un processo di sviluppo "serio", ovvero la tracciabilità dell'intero processo: i modelli, una volta arrivati al codice, non dovrebbero essere presi come riferimento per poi essere scartati una volta prodotto il codice, ma, piuttosto, essere usati per produrre la stragrande maggioranza di codice. Certo, poi si presenta il problema dell'allineamento modelli/codice, ma questo è un altro discorso.
Terminata la premessa, durante l'ultimo corso di ingegneria del software che ho seguito ho visto produrre in pochi secondi un prototipo a partire dai modelli sfruttando l'ambiente Eclipse e alcune features dell'ex pacchetto openarchitectureware, ora incorporato nell'Eclipse Modeling Framework.
Certo, alcune facility sono pensate per produrre codice Java, ma altre (per esempio, Xpand2) possono generare codice in un qualsiasi linguaggio a partire da un modello UML, anche perché le regole di traduzione si impostano a mano :)
È molto triste però constatare che in giro questi processi di produzione siano poco usati, preferendo il vecchio "codifica prima ancora di pensare"...

Avatar utente
RedSkull92
Linux 3.x
Linux 3.x
Messaggi: 567
Iscritto il: mar 21 apr 2009, 17:25
Slackware: 64bit -current
Kernel: 3.5.4
Desktop: FluxBox
Località: Palermo
Contatta:

Re: Sviluppo software & UML

Messaggio da RedSkull92 »


sir_alex
Linux 3.x
Linux 3.x
Messaggi: 735
Iscritto il: lun 21 mar 2005, 0:00
Kernel: 2.6.35-22
Desktop: KDE4
Distribuzione: Ubuntu
Località: Milano - Corbola (RO)
Contatta:

Re: Sviluppo software & UML

Messaggio da sir_alex »

Secondo me, l'utilizzo migliore che si possa fare di UML è come strumento di progettazione più "a volo d'uccello", non eccessivamente approfondita; è un approccio ben descritto dal buon Martin Fowler, peraltro, ed in pratica consiste nell'usare i diagrammi delle classi per definire le classi del tuo progetto, sorvolando sui dettagli minimi dei singoli metodi, ma concentrando soprattutto lo sforzo nel capire quali interfacce/classi astratte convenga creare, qual è l'aggregazione dei componenti e via dicendo. Tra l'altro, in un approccio del genere ti può bastare anche carta e penna.
Poi esistono tanti altri diagrammi in UML, probabilmente i più utili sono gli use-case ed i sequence, utili non solo a te ma anche se devi mostrare quali funzionalità deve avere l'applicativo finale, diciamo quindi in fase di raccolta delle informazioni.
In generale, l'approccio deve essere di creare prodotti facilmente estensibili, quindi facendo sì che una classe si occupi di poche cose (in teoria una sola, ma è spesso un po' eccessivo), e soprattutto che in qualunque punto tu veda un possibile sviluppo diversificato, tu crei interfacce ed astrazioni, così da poter estendere quel particolare aspetto anche in modi differenti in un secondo momento, cercando di risolvere i problemi che dicevi nel primo post.
Concordo peraltro con 414N, fare reverse engineering di codice per avere UML è abbastanza inutile, specialmente se lo fai sul tuo codice stesso: è il contrario la procedura corretta!

E' un po' che non uso Eclipse per gli UML, Omondo era il prodotto migliore (anche se pesante in maniera inguardabile), anche se purtroppo chiuso. Ultimamente, ho iniziato ad usare BoUML, piuttosto che Umbrello, che sinceramente non mi ha mai entusiasmato.

Avatar utente
lennynero
Linux 3.x
Linux 3.x
Messaggi: 641
Iscritto il: lun 3 mag 2004, 0:00
Nome Cognome: Luigi Picaro
Slackware: 15.0-x64
Kernel: 6.1
Desktop: Xfce-4.16
Località: Salerno

Re: Sviluppo software & UML

Messaggio da lennynero »

414N ha scritto:...il fatto di usarlo tramite reverse engineering su codice già esistente è segnale di un processo di sviluppo del software non ottimale.
Parto da questo passo della tua costatazione abbastanza condivisibile per cercare di spiegare meglio il mio punto di vista ed estendere il concetto di progettazione del software dicendo che: l'ottimizzazione dello sviluppo del codice presuppone sicuramente una progettazione formale di cio che si vuole realizzare, in termini di requisiti>scenari>funzionalità, ma come si sa il ciclo di vita del software è sempre pieno di evoluzioni che vanno debitamente gestite una per una. Non è possibile pensare che la progettazione accurata generi il codice ottimo, tuttavia è sicuramente un buon punto di partenza. Ma ora passiamo alla pratica, quando si decide di implementare un software, è fuori dubbio che non si parte scrivendo codice, una prima fase di analisi è obbligatoria(si parla di progetti medio-grandi), ma il punto cruciale è: quanto dedicare nel dettagliare la progettazione e quanto dedicare alla realizzazione reale. Questo passaggio è come sappiamo, sicuramente dipendente dalla tempistica di cui si dispone, non voglio dire che la progettazione è una perdità di tempo, ma si deve comunque fare una scelta di compromesso in molti casi.
414N ha scritto:In soldoni, si prendono i modelli prodotti durante l'analisi e si trasformano per adeguarli alle esigenze di implementazione, spesso rendendoli molto più dettagliati e dipendenti dalle scelte implementative. ...è poi possibile arrivare in un certo numero di passi alla generazione automatica della quasi interezza del codice necessario (non solo stub)
Questo approccio è sicuramente costruttivo, ma non tiene conto di alcune difficoltà tipiche, la modellazione può sicuramente descrivere le componenti in gioco e le relazioni tra esse, ma il comportamento di un componente è molto, almeno x me, difficile da astrarre, quello lo dettagli appunto in fase di implementazione(debitamente commentata). La generazione del codice nella sua quasi interezza è una situazione abbastanza rara in contesti medio-grandi e molto customizzati, ma sicuramente una buona parte del lavoro si risparmia, e soprattutto si standardizza... Io a dire la verità ho quasi sempre lavorato alla parte di progettazione in maniera abastanza scrupolosa, rigorosamente prima della stesura del codice, ma ho anche spesso affrontato la fase di riallineamento tra modelli e codice a cui facevi riferimento, e ti assicuro che se vuoi lavorare bene quella sarà la fase più frequente e impegnativa che si affronta.
Per quanto riguarda il reverse engineering io ho fatto questo esperimento per pura curiosità, ma con gli strumenti che ci sono in giro ti assicuro che si generano component diagram e class diagram molto descrittivi del codice, e assolvono comunque al ruolo di vista generale del funzionamento del software, quindi non penso sia inutile come è stato detto. Ovviamente c'è bisogno che alla base ci sia una struttura chiara ben definita. Io sostanzialmente dico che: facendo una progettazione ad alto livello, magari anche in maniera informale, si ha una prima bozza della propria architettura, poi la si mette in piedi a livello di codice stub+, e si passa al raffinamento, seguendo comunque dei dettami soggettivi che si ci è prefissato. In fase di sviluppo può anche capitare di voler intrudurre un design pattern per ottimizzare alcune procedure, o anche modificare una struttura precedentemente creata, questo va sicuramente ponderato, tenendo conto delle ripercussioni che tale decisione ha sul resto del progetto(impact analisys), e ad essere sincero a me è capitato di attuare tali cambiamenti direttamente sul codice, purtroppo è così, ma riallineando i modelli, anche a posteriori, non faccio altro che ripetere la procedura di reverse, sfruttando i feedback che mi restituisce per individuare falle nell'approccio di cui non mi ero accorto. Sostanzialmente ssto valutando la possibilità di sfruttare la modellazione, più formale, per effettuare controlli incrociati, e come istantanea del lavoro svolto, che può comunque tornare utile in contesti in cui la comunicazione con il cliente è parallela al processo di sviluppo, sicuramene non è il modo migliore, ma è un buon compromesso.

Su questo argomento sono un pò prolisso, me ne scuso, ma mi interessa molto, non nascondo che credo in questa strada, anche se mi sembra sempre il solito dilemma: piano e bene o svelto e approssimativo(ma sibuto fruibile)?!?, che spesso si risolve con la produzione di lavori mediocri a cui ci siamo assuefatti...

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2922
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 15.0
Kernel: 5.15.19
Desktop: KDE5
Località: Bulagna
Contatta:

Re: Sviluppo software & UML

Messaggio da 414N »

lennynero ha scritto: Per quanto riguarda il reverse engineering io ho fatto questo esperimento per pura curiosità, ma con gli strumenti che ci sono in giro ti assicuro che si generano component diagram e class diagram molto descrittivi del codice, e assolvono comunque al ruolo di vista generale del funzionamento del software, quindi non penso sia inutile come è stato detto.
Non mi sembra che nessuno abbia detto che il reverse engineering in UML sia inutile. Io ho solo detto che non è l'approccio ottimo in un processo di sviluppo di un nuovo software. In altri ambiti, per esempio integrazione di vecchio codice "legacy" in nuove applicazione o nuove versioni di applicazioni già esistenti, potrebbe essere l'unico metodo per uscirne sani di mente da un ammasso di codice scritto decenni prima da chissà chi...

Avatar utente
lennynero
Linux 3.x
Linux 3.x
Messaggi: 641
Iscritto il: lun 3 mag 2004, 0:00
Nome Cognome: Luigi Picaro
Slackware: 15.0-x64
Kernel: 6.1
Desktop: Xfce-4.16
Località: Salerno

Re: Sviluppo software & UML

Messaggio da lennynero »

sir_alex ha scritto:Concordo peraltro con 414N, fare reverse engineering di codice per avere UML è abbastanza inutile, specialmente se lo fai sul tuo codice stesso: è il contrario la procedura corretta!
Scusami 414N, io mi riferivo a sir_alex non a te, tra l'altro è probabile che lui ti abbia frainteso...
Cercavo solo di condividere una mia riflessione su una nuova interpretazione di modello>codice, trasformata in pre-modello>(codice>modello, manutenzione)*, mi aspettavo magari qualche parere su questo, non volevo animare nessuna polemica.

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2922
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 15.0
Kernel: 5.15.19
Desktop: KDE5
Località: Bulagna
Contatta:

Re: Sviluppo software & UML

Messaggio da 414N »

lennynero ha scritto: Scusami 414N, io mi riferivo a sir_alex non a te, tra l'altro è probabile che lui ti abbia frainteso...
Cercavo solo di condividere una mia riflessione su una nuova interpretazione di modello>codice, trasformata in pre-modello>(codice>modello, manutenzione)*, mi aspettavo magari qualche parere su questo, non volevo animare nessuna polemica.
No offense taken. :)
Mi era sfuggito quel pezzo di sir_alex e pensavo di dover chiarire meglio quanto scritto nel mio post precedente riguardo il reverse-engineering.

sir_alex
Linux 3.x
Linux 3.x
Messaggi: 735
Iscritto il: lun 21 mar 2005, 0:00
Kernel: 2.6.35-22
Desktop: KDE4
Distribuzione: Ubuntu
Località: Milano - Corbola (RO)
Contatta:

Re: Sviluppo software & UML

Messaggio da sir_alex »

Bè, è un fatto che dover fare reverse engineering di codice (e ricavare UML) scritto da altri è sicuramente sintomo del fatto che questi "altri" non hanno documentato adeguatamente il codice; fare reverse engineering del proprio codice è sintomo di errata progettazione, dato che UML viene a monte e non a valle del codice...

Avatar utente
lennynero
Linux 3.x
Linux 3.x
Messaggi: 641
Iscritto il: lun 3 mag 2004, 0:00
Nome Cognome: Luigi Picaro
Slackware: 15.0-x64
Kernel: 6.1
Desktop: Xfce-4.16
Località: Salerno

Re: Sviluppo software & UML

Messaggio da lennynero »

Sicuramente se si usa il reverse nel caso di reingegnerizzazione di sistemi legacy si presuppone che tali sistemi non erano stati modellati in UML, e visto che probabilmente l'UML non esisteva affatto quando sono stati progettati si potrebbe dire che non è colpa di nessuno. Invece per la progettazione di nuovi sistemi, non è che per forza si deve usare l'UML, altrimenti si sbaglia, è un supporto, e ognuno prova a servirsene nel modo più efficacie. Il mio scetticismo, sulla possibilità di investire molte risorse nella progettazione UML, risiede nel fatto che spesso in fase di implementazione vengono fuori nuovi vincoli e nuovi contesti che era impossibile prevedere in fase di design. Ovviamente si parla di dettagli implementativi, ma che spesso sono tanti, da qui l'impossibilità di pretendere una generazione semi-automatica di quasi tutto il codice, diciamo pure che si potrebbe generare semi-automaticamente quasi la metà del codice, e per la precisione, quello meno impegnativo...

Poi parliamoci chiaro, io ho ribadito già diverse volte, che il processo di sviluppo sarebbe più controllabile se si generasse il proprio software dai modelli, ma questo nella pratica voi lo fate? Sembra che stavamo andando leggermente off-topic, io mi aspettavo che qualcuno raccontasse la propria esperienza, e non che ci decantasse i pregi della modellazione. Offtopic: Quelli li conosciamo abbastanza bene, infatti i nostri meravigliosi docenti universitari sono maestri nel decantarle, anche senza leggere le slides..., i pregi dell'UML, ma poi litigano su cosa è un caso d'uso inventano punti di vista che poi smentiscono, e ti cambiano i requisiti in fase di sviluppo, facendotela sembrare una cosa banale e di lieve impatto, dimenticandosi che la mattina ti avevano "spiegato" quanto era importante distinguere le fasi.... (adesso mi sono sfogato un pò anche io). comunque la domanda di tgmx era: voi come procedete? io ho risposto, provateci anche voi, e magari dopo commentiamo anche i diversi approcci...

sir_alex
Linux 3.x
Linux 3.x
Messaggi: 735
Iscritto il: lun 21 mar 2005, 0:00
Kernel: 2.6.35-22
Desktop: KDE4
Distribuzione: Ubuntu
Località: Milano - Corbola (RO)
Contatta:

Re: Sviluppo software & UML

Messaggio da sir_alex »

Bè, per la verità io ho già detto come mi comporto: usando soprattutto diagrammi di classe per descrivere le entità presenti nel sistema, senza scendere troppo nel dettaglio, come Fowler insegna; inoltre uso use-cases e sequence per chiarire le idee sui passaggi che una procedura seguirà nell'applicativo.

Avatar utente
lennynero
Linux 3.x
Linux 3.x
Messaggi: 641
Iscritto il: lun 3 mag 2004, 0:00
Nome Cognome: Luigi Picaro
Slackware: 15.0-x64
Kernel: 6.1
Desktop: Xfce-4.16
Località: Salerno

Re: Sviluppo software & UML

Messaggio da lennynero »

Forse allora sono stato io a non aver capito che tu applicavi quel metodo, perché avevi iniziato dicendo: "secondo me l'utilizzo migliore che si possa fare è...", e questa cosa non so perché mi ha fuorviato e non ho pensato che la attuassi davvero, caspita i sequence io non riesco a pensare di farli prima...

Avatar utente
tgmx
Linux 4.x
Linux 4.x
Messaggi: 1336
Iscritto il: ven 28 apr 2006, 14:40
Slackware: 14.1
Desktop: KDE 4
Località: Ancona

Re: Sviluppo software & UML

Messaggio da tgmx »

Ottimi spunti,
il fatto è proprio capire se ci sono realtà in cui viene applicata alla lettera la teoria della modellazione.
A volte è capitato anche a me di avere abbastanza tempo per fare un'analisi approfondita del problema da affrontare ma a volte qundo arriva in ufficio "l'ordine" si è già in ritardo sulla consegna e non si hanno ancora tutte le specifiche quindi o si aspetta che arrivino tutte le info necessarie o si inizia a buttare giù qualcosa cercando di tenersi "larghi" per poter poi applicare le variazioni in un secondo tempo.
Solo a me capitano situazioni del genere? :D

Quando si parla di "use cases diagram" o di "sequence diagram" utilizzate carta e penna, eclipe o cosa?

Rispondi