Ribaltate la prospettiva

Molti i team hanno l'abitudine di iniziare a sviluppare un'applicazione partendo dalla progettazione del database e costruendo su di esso le classi partendo dal DAL e risalendo fino all'interfaccia utente. Questo approccio (Bottom Up) porta a due conseguenze:
1) L'interfaccia utente è relegata alle fasi finali e la sua realizzazione viene compiuta in fretta secondo le logiche e i meccanismi dettati dagli strati inferiori. Questo vuol dire che spesso per compiere un'operazione anche semplice l'utente deve fare diversi "giri" poco naturali solo perchè sotto il metodo che riceve l'input ha una certa firma e cambiarlo vuol dire modificare tutti gli strati dalla UI fino al DAL.
2) Gli strati più bassi, DAL e Business Layer, sono composti da una moltitudine di metodi spesso inutili, non indipendenti e difficili da usare. Questo perchè durante lo sviluppo del DAL non si hanno ancora le idee chiare su come l'utente opererà al livello della UI e quindi i metodi scritti risultano essere di basso livello e poco "usabili" anche per il programmatore.

Invito tutti a provare a ribaltare l'approccio partendo insieme all'utente a disegnare l'interfaccia (anche su carta va benissimo) e progettare gli altri strati dell'applicazione sulla base delle richieste dell'utente. In questo modo tutto ciò che andrete a scrivere è orientato a ciò che deve essere fatto evitanto la proliferazione di metodi inutili e difficili da usare.

Print | posted on martedì 20 marzo 2007 11.02

Comments on this post

# re: Ribaltate la prospettiva

Requesting Gravatar...
Sottoscrivo in pieno le tue considerazioni: decisamento MOLTO meglio un approccio "up-bottom" al classico "bottom-up" (provato sulla mia pelle!).
Le funzionalità di un'applicazione sono (e *devono essere*) dettate dalle esigenze dell'utente ( chi è figo e usa UML li chiama "use cases diagrams" ma la sostenza non cambia :-) ) e non da quello che il programmatore ha in testa ("class diagrams" o che altro).
In caso contrario il rischio di avere un sacco di classi/metodi inutili a diposizione (a fronte della mancanza di classi/metodi necessari) è dietro l'angolo ed aumenta proporzionalmente alla complessità dell'applicazione.
Nel caso migliore avremo un sensibile degrado delle performance, in quello peggiore avremo buona parte dell'applicazione da riscrivere... Provare per credere! :-)
Left by Matteo Casati on mar 20, 2007 12.31

# Re: Ribaltate la prospettiva

Requesting Gravatar...
Esatto.
E si puo sempre fare un mock del service layer se serve testare subito l'interfaccia con dati che vengono dal basso.
Left by Michele Bersani on mar 20, 2007 1.55

# re: Ribaltate la prospettiva

Requesting Gravatar...
Approccio corretto ma attenzione a non commettere l'errore di realizzare interamente l'interfaccia utente e presentarla al cliente "per l'approvazione" perché questi crederà che l'applicazione sia finita o manchi poco alla conclusione mentre in realtà manca tutto lo strato applicativo.

E' saggio inserire nell'interfaccia dei "segnali di lavoro in corso" che facciano comprendere che quello che si sta presentando è un semilavorato e non un'applicazione completa.

Saluti, Alessandro
Left by Alessandro Ronchi on ago 13, 2007 10.13

Your comment:

 (will show your gravatar)
 
Please add 4 and 7 and type the answer here: