Come gestire i requisiti e i casi d'uso in questo tipo di situazione?

0

Recentemente ho iniziato a lavorare con analisi e progettazione orientata agli oggetti e mi è sembrato molto interessante come un modo per migliorare il lavoro. Ma sono ancora in dubbio con un tipo di situazione. Se questo non è il sito giusto per chiederglielo, scusami.

Bene, se devo progettare un sistema che consente a un utente di registrare clienti, vendere prodotti e così via, abbiamo qualcuno che gestirà il sistema, nel senso che l'attore è ovvio per alcuni dei casi d'uso - l'attore che considereremo nel caso d'uso "Registra nuovo cliente" è semplicemente il responsabile di tale azione nella società del cliente che acquista il software.

Ora, a volte ciò non accade. Darò un esempio: ho sviluppato una volta un sistema per gestire modelli per siti Web in PHP. A quel tempo, non l'ho sviluppato all'interno di un contesto orientato agli oggetti, ma stavo pensando di portare questo sistema nell'orientamento agli oggetti per praticare l'analisi e la progettazione orientata agli oggetti. Il punto è che il sistema è molto semplice: "ci vogliono alcune configurazioni scritte in un file xml, prende un URL e lo mappa su un file".

Il punto è che non c'è interazione tra gli utenti dei siti web e il sistema. L'unica cosa che succede è che l'utente richiede un URL e il sistema seleziona un file html che corrisponde a questo URL in qualche modo e incorpora questo html in un modello specificato in xml. In casi come questo, gli unici requisiti funzionali che posso pensare sono:

  • Il sistema deve consentire all'utente di specificare le cartelle di modelli in un file xml;
  • Il sistema deve ottenere le informazioni delle directory dal file xml;
  • Il sistema deve caricare un file specifico corrispondente all'URL richiesto all'interno di un file di modello;
  • Il sistema deve consentire la sostituzione dei segnaposto nel modello con i valori specificati nel codice;

Il problema è: ad esempio, anche se li ho considerati requisiti funzionali, tutti devono fare direttamente come deve essere fatto il codice. Solo il terzo si adatta perfettamente a ciò che ho capito del requisito funzionale. Anche i casi d'uso sono un po 'complicati, ogni azione è intrapresa dal sistema stesso. L'unico caso d'uso potrebbe essere "Pagina richiesta" con l'attore "Visitatore sito" e ciò implicherebbe che lo scenario sarebbe solo "L'utente inserisce l'URL nella finestra del browser e il sistema carica la pagina."

Quindi, in casi come questo, quando abbiamo a che fare con il codice sarà semplicemente riutilizzato in qualche altro codice (questo è un esempio, è solo un mucchio di codice che uno sviluppatore può usare per caricare pagine indipendentemente da un modello), come dovremmo occuparci dell'analisi dei requisiti, dei casi d'uso e così via?

Come ho già detto, il sistema PHP che ho scritto è solo un esempio, lo chiedo in generale. Qualcuno potrebbe dare qualche suggerimento o riferimento (qualche articolo, tutorial, qualcosa del genere), che mostra come affrontare questo?

Grazie mille in anticipo!

    
posta user1620696 26.07.2013 - 04:45
fonte

2 risposte

3

Gli attori non devono essere persone!

Qualsiasi sistema, dispositivo o programma esterno può essere un attore fintanto che è riconoscibile un'entità separata che utilizza o è utilizzata dal sistema che stai sviluppando.

Gli attori tecnici di solito rientrano nella categoria "used by", ad esempio "Authentication Server", "Payment Processor" ecc.

Nel tuo caso, però, sembrerebbe ruotare attorno a due soli casi d'uso. "Il sistema richiedente riceve l'output reso" e forse "L'amministratore definisce il modello"

    
risposta data 26.07.2013 - 08:42
fonte
2

Use cases come Register New Customer appartengono alla vista business o dominio e descrivono le interazioni tra gli utenti finali e sistema.

Lo scopo dei casi d'uso è consentire la comunicazione tra lo sviluppatore del software e gli utenti finali non tecnici, i soggetti interessati, i gestori.

I casi d'uso descrivono what has to be done ma non how is it implemented .

Le tue frasi The system must ... descrivono how is it implemented che sono importanti dettagli di implementazione. A mio avviso, i dettagli di implementazione non appartengono ai casi d'uso. Gli utenti finali di solito non sono interessati a cartelle, xml, file, segnaposto. Nel tuo sistema, gli utenti finali vogliono registrare nuovi clienti e vendere loro qualcosa.

    
risposta data 26.07.2013 - 07:09
fonte

Leggi altre domande sui tag