Question

在代码

中试验Cockburn用例

我正在编写一些复杂的UI代码。我决定使用带有鱼，风筝和海平面的Cockburn用例（Martin Fowler在他的书“UML Distilled”中讨论过）。我将Cockburn用例包装在静态C＃对象中，以便我可以针对静态常量测试逻辑条件，静态常量表示UI工作流中的步骤。我的想法是你可以阅读代码并知道它在做什么，因为包装的对象及其公共内容通过命名空间为你提供了ENGLISH用例。

此外，我将使用反射来抽出包含所描述的用例的错误消息。这个想法是堆栈跟踪可以包括一些用例步骤IN ENGLISH ....事实证明这是一种有趣的方式来实现迷你，伪造轻量级域语言，但无需编写DSL编译器。所以我的问题是这是否是一个很好的方法呢？有没有人在那里做过类似的事情？

c＃示例代码段跟随

假设我们有一些aspx页面，它有3个用户控件（有很多可点击的东西）。用户必须点击一个特定用户控件中的内容（可能进行某种选择），然后UI必须在视觉上提示用户选择成功。现在，在选择该项目时，用户必须浏览网格视图以在其中一个用户控件中查找项目，然后选择一些内容。这听起来很容易管理，但代码可能变得丑陋。

在我的情况下，用户控制主页捕获的所有已发送事件消息。这样，页面就像UI事件的中央处理器一样，可以跟踪用户点击时发生的情况。

因此，在主aspx页面中，我们捕获了第一个用户控件的事件。

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


     }
  }

}

因此，在MyCompany.MyApp.Web.UseCases命名空间中，我们可能有这样的代码：

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

嵌入在类中的工作流用例可以是内部类或静态方法或枚举，也可以是任何为您提供最干净的命名空间的工具。我不记得我原来做了什么，但是你得到了照片。

Answer 1

我从来没有这样做过，但我经常考虑用UC风格编写代码，首先是主成功路径，然后是下面列出的例外扩展。没有找到理由这样做 - 很想看到有人尝试并编写代码，即使在实验结束后我们认为它很糟糕，尝试并参考它仍然会很有趣。

Answer 2

我认为这是来自设计模式（四人帮）的Mediator模式的变体 - 所以我想说这是一种有效的方法。在模式中，他们讨论了控件之间复杂的交互是使用它的原因。

修改：链接到Mediator on Wikipedia

是否可以在代码库中嵌入Cockburn样式的文本UML用例内容以提高代码可读性？

在代码

2 个答案: