Experimentando con los casos de uso de Cockburn en código.

Estaba escribiendo un código de interfaz de usuario complicado. Decidí emplear los casos de uso de Cockburn con peces, cometas y niveles del mar (discutido por Martin Fowler en su libro 'UML Distilled'). Envolví los casos de uso de Cockburn en objetos C # estáticos para poder probar las condiciones lógicas con las constantes estáticas que representaban los pasos en un flujo de trabajo de IU. La idea era que usted pudiera leer el código y saber qué estaba haciendo porque los objetos envueltos y sus contendientes públicos le dieron casos de uso en INGLÉS a través de espacios de nombres.

Además, iba a utilizar la reflexión para bombear mensajes de error que incluían los casos de uso descritos. La idea es que el seguimiento de la pila podría incluir algunos pasos de casos de uso de la interfaz de usuario EN INGLÉS ... Resultó ser una forma divertida de lograr un lenguaje de dominio mini, ligero y ligero, pero sin tener que escribir un compilador DSL. ¿Entonces mi pregunta es si esta es o no una buena manera de hacer esto? ¿Alguien por ahí alguna vez ha hecho algo similar?

c # ejemplos de fragmentos siguen

Supongamos que tenemos alguna página aspx que tiene 3 controles de usuario (con muchas cosas para hacer clic). El usuario debe hacer clic en el contenido de un control de usuario en particular (posiblemente hacer algún tipo de selección) y luego la IU debe indicar visualmente al usuario que la selección fue exitosa. Ahora, mientras ese elemento está seleccionado, el usuario debe navegar a través de una vista de cuadrícula para encontrar un elemento dentro de uno de los otros controles del usuario y luego seleccionar algo. Esto parece algo fácil de manejar, pero el código puede ser feo.

En mi caso, el usuario controla todos los mensajes de eventos enviados que fueron capturados por la página principal. De esta manera, la página actuó como un procesador central de eventos de IU y podría hacer un seguimiento de lo que sucede cuando el usuario está haciendo clic.

Entonces, en la página principal de aspx, capturamos el evento del primer control de usuario.

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...


     }
  }

}

Por lo tanto, en el espacio de nombres MyCompany.MyApp.Web.UseCases podríamos tener un código como este:

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

Los casos de uso del flujo de trabajo incrustados en las clases podrían ser clases internas o métodos estáticos o enumeraciones, o lo que sea que le proporcione el espacio de nombres más limpio. No puedo recordar lo que hice originalmente, pero te haces una idea.