Workflow di analisi e progettazione orientata agli oggetti per gli sviluppatori che lavorano da soli

Naviga le tue risposte
2

Studiando su OOAD ho trovato un flusso di lavoro semplice basato su cinque passaggi. Non lavoro con un team, quindi quello che mi interessa è un flusso di lavoro che può essere utilizzato da uno sviluppatore che lavora da solo. Il flusso di lavoro che ho trovato è:

  1. Raccogli i requisiti per l'applicazione
  2. Descrivi l'applicazione con casi d'uso
  3. In base ai casi d'uso, identifica gli oggetti principali
  4. Identifica le relazioni tra gli oggetti trovati
  5. Scrivi un diagramma di classe

Ora, ci sono due cose su questo flusso di lavoro che mi rende un po 'confuso: prima sembra eccessivamente semplificato, e in secondo luogo sembra trattare solo con il livello del dominio, ma non ne sono sicuro.

Quindi, le mie domande sono:

  1. Questo flusso di lavoro è ok o è eccessivamente semplificato?
  2. In tal caso, quali ulteriori informazioni potrebbero essere aggiunte per rendere più chiaro il modo di procedere dai requisiti fino al diagramma di classe?
  3. Ho ragione nel dire che tutto questo riguarda il modello di dominio?
  4. Quando eseguiamo OOAD, includiamo sul modello e sui diagrammi delle classi altre classi che potrebbero essere necessarie per connettere il modello di dominio alle tecnologie? O su questo passo ci occupiamo solo di modellare il dominio dell'applicazione?
posta user1620696 11.02.2015 - 14:34
fonte

1 risposta

3

Questo flusso di lavoro sembra piuttosto semplicistico e in qualche modo non utile per me:

  1. Presuppone che tutti i requisiti della tua applicazione possano essere acquisiti come casi d'uso, ma i casi d'uso sono descrizioni astratte delle operazioni che devono essere eseguite sui dati memorizzati che (a) non descrivono l'interfaccia utente e (b) non descrivere i meccanismi di archiviazione. Vorrei, insieme ai casi d'uso, produrre uno schizzo dell'interfaccia utente e un piano di archiviazione dei dati, poiché questi influenzeranno anche il design della soluzione.

  2. Raramente vedo il vantaggio nella produzione di un diagramma di classe prima del codice. I diagrammi di classe sono utili per descrivere un sistema ad altre persone, ma quando si lavora da soli o in piccoli gruppi la comunicazione tende a non essere necessaria molto tempo dopo, e il design di solito cambia abbastanza per rendere i diagrammi prodotti prima che il codice sia obsoleto prima di essere utili. Vai direttamente al codice.

  3. Il flusso di lavoro sembra presupporre che è possibile analizzare e quindi implementare l'intera applicazione in un unico passaggio. Per qualcosa che non sia la più semplice delle applicazioni, questo non è realistico. Progetta e implementane una parte, quindi ripeti fino alla fine.

risposta data 11.02.2015 - 20:03
fonte

Leggi altre domande sui tag

Inizializza le risorse fisiche nel costruttore Il punto più vicino all'obiettivo mobile