metodologia d'analisi
severus
dovendo affrontare l'analisi / sviluppo di un progetto di medie
dimensioni con Erlang e potendosi avvalere della collaborazione di
diversi gruppi di lavoro, quale metodologia d'analisi utilizzereste ?
Grazie Roberto
Corrado Santoro
severus wrote:
> dovendo affrontare l'analisi / sviluppo di un progetto di medie
> dimensioni con Erlang e potendosi avvalere della collaborazione di
> diversi gruppi di lavoro, quale metodologia d'analisi utilizzereste ?
Cosa intendi per "metodologia"? Stai parlando di qualcosa di
standardizzato nel mondo del software engineering? Oppure stai usando il
termine in modo generico?
Supponiamo il secondo caso (che e' sempre quello piu' comune :-) ).
Posso dirti la mia esperienza in questo senso, che pero' non so se puo'
essere applicata per intero al tuo caso. Io ho lavorato con gruppi
abbastanza piccoli (al piu' una decina di persone) e ho seguito questo
approccio.
1. Note le specifiche (ma sono tutte note?) facciamo un meeting iniziale
volto a discutere insieme le caratteristiche dell'applicazione da
realizzare; da questa discussione di solito emergono un certo numero di
"moduli software", oppure piu' precisamente "erlang application" (thanks
Enzo Nicosia! :-) ), con delle funzionalita' determinate. A questo punto
si assegnano i moduli alla varie persone e/o gruppi. E' importante
determinare in questo caso il "grafo delle dipendenze" dei vari moduli,
in modo da capire i tempi di sviluppo, organizzare gli incontri di
integrazione, stabilire le scadenze intermedie. A questo scopo, un
diagramma di Gantt e' abbastanza utile.
2. Ogni persona e/o gruppo definisce le interfacce che il modulo (o i
moduli) di cui ci occupa devono offrire. In genere tali moduli sw
saranno composti da uno o piu' gen_server o gen_fsm. Per interfaccia
intendo ovviamente funzioni esportate, loro parametri e valori di ritorno.
3. Si fanno circolare tali documenti di specifica, si revisionano e si
approvano in prima istanza; si procede allora all'implementazione, non
senza aver deciso la struttura delle directory del source tree (usare un
svn o cvs e' abbastanza fondamentale in questi casi).
4. Si stabiliscono delle date precise per i "meeting di integrazione",
dove uno o piu' gruppi/persone si incontrano e integrano i moduli
realizzati, individuando se le interfacce corrispondo a quelle definite
e/o a quelle attese dagli altri. Si procede al review del codice ed al
bug fixing fin quando l'integrazione non ha avuto successo.
5. Si reitera 3-4 alla luce di eventuali correzioni alle specifiche e/o
esigenze di implementazione che possono venire fuori.
Ovviamente in tutto questo la scrittura di test e' fondamentale ed e'
anche importante che uno o piu' persone abbiamo consapevolezza delle
funzionalita' e della struttura del codice dell'intero progetto, in modo
che possano coordinare al meglio le attivita'.
Il livello di "isolamento" delle parti software dovrebbe poi essere,
secondo me, dipendente dalle dimensioni del team di sviluppo: piu'
persone ci sono, piu' i vari moduli dovrebbero essere "autocontenuti" in
modo da evitare che ritardi sullo sviluppo di una parte possa influire
pesantemente sullo sviluppo di altre parti.
Per il resto.... ci vuole molto buon senso e olio di gomito :-)
Spero di esserti stato utile.
--Corrado
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty
Tel: +39 095 7382380 VoIP: sip:70...@voicegw2.diit.unict.it
Personal Home Page: http://www.diit.unict.it/users/csanto
NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
Michele Sciabarra
Erlang puoi benissimo usare UML,
ma non servono i diagrammi delle classi (che invece sono fondamentali
con Java).
Invece usi moltissimo i diagrammi di deployment, sono VITALI i sequence
diagram (come si vede anche sul libro di Armstrong) e il flusso dei
messaggi lo modelli bene con un activity diagram.
In realta' ho lavorato con un progetto a Londra che era un gigantesco
sistema a scambio di messaggi (e' da li' che e' nato il mio interesse
per Erlang), e serviva a gestire sms per Telco.
Bene, tutto veniva progettato usando dei digrammi di flusso disegnati
con visio (che poi era un activity diagram) , e la logica di ogni
messaggio veniva modellata nei documenti di analisi con dei sequence
diagram.
severus
Il problema nasce dal fatto che un cliente della mia azienda
vuole affrontare lo sviluppo di un prototipo in Erlang e visto
i tempi di realizzazione molto stretti, vorrebbe affidare l'analisi
ad un gruppo di persone, mentre lo sviluppo ad altre due societa'
distinte; conseguentemente a questo:
1) L'analisi verra' fatta da persone che parteciperanno si allo
sviluppo, ma in una seconda fase.
2) Le societa' che si occuperanno all'ottanta percento dello
sviluppo svilupperanno in "casa loro", quindi avranno pochi contatti
con la parte d'analisi, se non attraverso un paio di capi progetto
che saranno coinvolti nelle varie riunioni.
A seguito di questo il cliente chiede un'analisi molto dettagliata
e mi chiedevo appunto se sviluppando con un linguaggio funzionale
esistono delle tecniche di software engineering che voi utilizzate
abitualmente.
Normalmente le analisi che mi vengono richieste sono inerenti a
linguaggi OO (uso UML) e questa sarebbe la prima volta che affronto
un'analisi di un progetto di dimensioni medie in Erlang in cui sono
"costretto" a staccarmi completamente dalla parte di sviluppo
(normalmente affronto il problema con un metodo molto simile al tuo
e partecipo attivamente allo sviluppo).
Ciao e grazie
Roberto
Corrado Santoro
severus wrote:
> A seguito di questo il cliente chiede un'analisi molto dettagliata
> e mi chiedevo appunto se sviluppando con un linguaggio funzionale
> esistono delle tecniche di software engineering che voi utilizzate
> abitualmente.
Io non ho utilizzato tecniche particolari di SE nei progetti che ho
affrontato; ma comunque, a mio parere e come suggeriva Michele, UML puo'
andare benissimo.
In realta' UML l'abbiamo usato per documentare un progetto gia' fatto; i
diagrammi delle classi secondo me possono essere molto utili se pensati
in termini di "processi", cioe' considerando che ogni classe (o oggetto)
corrisponde ad un processo Erlang magari modellato come gen_server o
gen_fsm (e questo potrebbe corrispondere ad una classe "base" astratta).
Anche il concetto di aggregazione potrebbe essere utile quando, ad
esempio, hai un processo che possiede, nel suo stato, un riferimento ad
altri processi (cioe' i loro "pid", pensa ad un supervisor che possiede
i pid dei worker e quindi, in qualche modo "aggrega" i worker).
Rispetto ad un linguaggio OO qui la differenza, secondo me, e' nella
granularita' delle classi; in Java o C++ uno ha l'abitudine di mappare
qualunque cosa in una classe, a partire dal dato strutturato fino alle
parti di codice attivo. In Erlang hai molta meno "pollution": i dati li
tratti tranquillamente con tuple, liste e record, mentre quello che
andrebbe messo in un "class-diagram-equivalente" sono solo le parti di
codice attivo e cioe' i processi.
Anche i sequence diagram possono essere molto utili per definire le
interazioni tra i vari processi. Tuttavia, se usi OTP e quindi modelli
tutto con gen_server o gen_fsm non dovresti avere bisogno di definire
nel dettaglio il flusso di messaggi, ma dovrebbero bastare le
invocazioni delle funzioni (il messaggio e la conseguente "handle_call"
e' qualcosa che puoi pensare gestita "internamente").
In ogni caso, io credo che questo (SE in Erlang) sia un argomento molto
interessante e non mi pare che sia stato affrontato in modo approfondito
ne' in lista (erlang-questions) ne' da parte dei ricercatori.
Potrebbe essere interssante continuare a discuterne... :-)
A presto,
--C.
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty
Tel: +39 095 7382380 VoIP: sip:70...@voicegw2.diit.unict.it