coding-style - type - use case uml software




È possibile incorporare il contenuto UML dei casi d'uso testuali in stile Cockburn nel codice base per migliorare la leggibilità del codice? (2)

Penso che questa sia una variante del modello di mediatore di Patterns di progettazione (Gang of Four), quindi direi che è un modo valido per farlo. Nel Pattern, discutono che la complicata interazione tra i controlli è la ragione per usarla.

Modifica: collegamento al mediatore su Wikipedia

sperimentando casi di uso di Cockburn nel codice

Stavo scrivendo un complicato codice UI. Ho deciso di utilizzare i casi di uso di Cockburn con pesci, aquiloni e livelli del mare (discussi da Martin Fowler nel suo libro "UML Distilled"). Ho avvolto i casi di uso di Cockburn in oggetti C # statici in modo da poter testare condizioni logiche contro costanti statiche che rappresentavano passi in un flusso di lavoro dell'interfaccia utente. L'idea era che si potesse leggere il codice e sapere cosa stava facendo perché gli oggetti incartati e i loro contendenti pubblici ti fornivano casi d'uso in inglese tramite i namespace.

Inoltre, stavo per usare la riflessione per estrarre messaggi di errore che includevano i casi d'uso descritti. L'idea è che la traccia dello stack potrebbe includere alcuni passaggi del caso d'uso dell'interfaccia utente IN INGLESE .... Si è rivelato un modo divertente per ottenere un linguaggio di dominio leggero mini, psuedo ma senza dover scrivere un compilatore DSL. Quindi la mia domanda è se questo è un buon modo per farlo? Qualcuno là fuori ha mai fatto qualcosa di simile?

seguono gli esempi di esempio c #

Supponiamo di avere una pagina di aspx che ha 3 controlli utente (con un sacco di cose cliccabili). L'utente deve fare clic su elementi in un particolare controllo utente (possibilmente facendo una specie di selezione) e quindi l'interfaccia utente deve indurre visivamente l'utente che la selezione ha avuto successo. Ora, mentre quell'elemento è selezionato, l'utente deve navigare attraverso una griglia per trovare un oggetto all'interno di uno degli altri controlli utente e quindi selezionare qualcosa. Sembra una cosa facile da gestire, ma il codice può diventare brutto.

Nel mio caso, l'utente controlla tutti i messaggi di evento inviati che sono stati catturati dalla pagina principale. In questo modo, la pagina si comportava come un processore centrale di eventi dell'interfaccia utente e poteva tenere traccia di ciò che accade quando l'utente fa clic.

Quindi, nella pagina principale di Aspx, acquisiamo il primo evento del controllo utente.

using MyCompany.MyApp.Web.UseCases;   

protected void MyFirstUserControl_SomeUIWorkflowRequestCommingIn(object sender, EventArgs e)
{
  // some code here to respond and make "state" changes or whatever
  //
  // blah blah blah


  // finally we have this (how did we know to call fish level method?? because we knew when we wrote the code to send the event in the user control)
  UpdateUserInterfaceOnFishLevelUseCaseGoalSuccess(FishLevel.SomeNamedUIWorkflow.SelectedItemForPurchase)

}



protected void UpdateUserInterfaceOnFishLevelGoalSuccess(FishLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case FishLevel.SomeNamedUIWorkflow.NewMasterItemSelected:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.DrillDownOnDetails:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.CancelMultiSelect:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;

     // more cases...


     }
  }

}


//also we have
protected void UpdateUserInterfaceOnSeaLevelGoalSuccess(SeaLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case SeaLevel.CheckOutWorkflow.ChangedCreditCard:
        // do stuff


     // more cases...


     }
  }

}

Quindi, nello spazio dei nomi MyCompany.MyApp.Web.UseCases potremmo avere un codice come questo:

class SeaLevel...
class FishLevel...
class KiteLevel...

I casi di utilizzo del flusso di lavoro incorporati nelle classi possono essere classi interne o metodi statici o enumerazioni o qualsiasi altro tipo di spazio dei nomi più pulito. Non riesco a ricordare quello che ho fatto in origine ma ottieni l'immagine.


Non l'ho mai fatto, ma ho spesso pensato di scrivere codice in stile UC, con il principale percorso di successo prima e le estensioni inserite come eccezioni catturate di seguito. Non ho trovato la scusa per farlo - mi piacerebbe vedere qualcuno provarlo e codice, anche se dopo l'esperimento concludiamo che è terribile, sarà comunque interessante provare e fare riferimento.





use-case