al momento sto guardando il corso di Lynda.com sulle basi di Object Oriented Design e una domanda continua a venirmi in mente.
Quando dovrei usare Use cases e quando dovrei usare User Story?
E la stessa domanda vale per l'altra parte
Quando dovrei usare le carte CRC e quando dovrei usare un modello concettuale di oggetti?
Posso usare uno e "saltare" l'altro? Sono complimenti l'un l'altro?
Puoi usare quello che ti è comodo. I casi d'uso "completamente vestiti" tendono ad essere più prolissi e dettagliati. Le storie degli utenti, d'altra parte, coinvolgono input che provengono direttamente dagli utenti, ed è solitamente una descrizione molto breve che è meno dettagliata. Detto questo, spingono più del lavoro di progettazione nella fase di codifica, che la maggior parte degli sviluppatori preferisce.
Le cose sui requisiti sono cambiate molto velocemente. Le storie degli utenti sono un pilastro dello sviluppo agile e / o basato sui test. Se hai frequenti comunicazioni con gli stakeholder dell'applicazione e puoi aggiornare l'applicazione su cui stai lavorando ogni due settimane e ogni due settimane, puoi ottenere un feedback immediato dai tuoi utenti, quindi le user story probabilmente sono la strada da percorrere.
D'altro canto, se stai lavorando con alcuni ragazzi offshore che leggono l'inglese meglio di come lo parlano, allora i casi d'uso potrebbero essere la soluzione giusta per quel progetto. Inoltre, se stai lavorando su un'app più critica, che potrebbe far saltare in aria qualcosa se si è imboccata la strada sbagliata, potresti avere bisogno di specifiche più dettagliate in anticipo.
Per quanto riguarda CRC vs COM, sono entrambi utilizzati per la progettazione. Personalmente, personalmente mi piacciono il CRC e il design guidato dalla responsabilità. Detto questo, puoi fare la stessa cosa con casi d'uso e un COM UML. Nel caso d'uso + nel caso COM, più design è fatto al di fuori della codifica, che spesso finisce per cambiare durante la fase di codifica.
Se stai facendo Test Driven Development (TDD), definirai il tuo codice attraverso una serie di test che garantiscono che il tuo codice soddisfi i suoi requisiti. In questo modo, non stai scrivendo alcun codice aggiuntivo, solo ciò che è necessario per soddisfare i requisiti.
La cosa più importante è eliminare i principi dall'OOD. Una volta compreso, puoi utilizzare qualsiasi metodo che ti conviene.
Scrum è un processo di progetto agile molto popolare utilizzato da molti team in questi giorni, potresti voler esaminare questo: link
Un'altra cosa che potresti voler esaminare è BDD link
Ecco un esempio dalla stessa pagina di una storia utente con specifiche comportamentali.
Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned Scenario 1: Refunded items should be returned to stock Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock Scenario 2: Replaced items should be returned to stock Given that a customer buys a blue garment And I have two blue garments in stock And three black garments in stock. When he returns the garment for a replacement in black, Then I should have three blue garments in stock And two black garments in stock
Leggi altre domande sui tag object-oriented-design