是否可以在代码库中嵌入Cockburn样式文本UML用例提高代码可读性的内容？ [英] Is it possible to embed Cockburn style textual UML Use Case content in the code base to improve code readability?

问题描述

在代码中尝试Cockburn用例

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

将使用反射来泵出包括所描述的用例的错误消息。这个想法是，堆栈跟踪可以包括一些UI用例步骤IN ENGLISH ....结果证明是一个有趣的方式来实现一个迷你，伪造的轻量级域语言，但不必编写DSL编译器。所以我的问题是，这是否是一个好的方法这样做？有没有人有做过类似的东西？

---

c＃范例程式码片段如下

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

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

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

 code>使用MyCompany.MyApp.Web.UseCases; 
 
 protected void MyFirstUserControl_SomeUIWorkflowRequestCommingIn（object sender，EventArgs e）
 {
 //一些代码在这里响应和进行状态更改或任何
 // 
 // blah blah blah 
 
 
 //最后我们有了这个（我们怎么知道调用鱼水平方法，因为我们知道当我们写代码发送事件用户控件）
 UpdateUserInterfaceOnFishLevelUseCaseGoalSuccess（FishLevel.SomeNamedUIWorkflow.SelectedItemForPurchase）
 
 
 
 
 
 protected void UpdateUserInterfaceOnFishLevelGoalSuccess（FishLevel.SomeNamedUIWorkflow goal） 
 {
 {
 switch（goal）
 {
 case FishLevel.SomeNamedUIWorkflow.NewMasterItemSelected：
 //调用一些UI相关的方法，包括其他用户控件的方法.... 
 break; 
 case FishLevel.SomeNamedUIWorkFlow.DrillDownOnDetails：
 //调用一些UI相关的方法在这里包括其他用户控件的方法如果必要.... 
 break; 
 case FishLevel.SomeNamedUIWorkFlow.CancelMultiSelect：
 //调用一些UI相关的方法，包括其他用户控件的方法，如果必要.... 
 break; 
 
 //更多情况... 
 
 
} 
} 
 
} 
 
 
 //我们有
 protected void UpdateUserInterfaceOnSeaLevelGoalSuccess（SeaLevel.SomeNamedUIWorkflow goal）
 {
 switch（goal）
 {
 case SeaLevel.CheckOutWorkflow.ChangedCreditCard ：
 // do stuff 
 
 
 //更多情况... 
 
 
} 
} 
 
} 
  

因此，在MyCompany.MyApp.Web.UseCases命名空间中，像这样：

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

嵌入在类中的工作流用例可以是内部类或静态方法或枚举，最清晰的命名空间。

解决方案

我从来没有这样做过，经常想到在UC风格中编写代码，主要成功路径第一和扩展作为异常捕获下面。没有找到借口做它 - 很想看到有人尝试它和代码，即使在实验后，我们认为它是可怕的，它仍然是有趣的尝试和参考。

experimenting with Cockburn use cases in code

I was writing some complicated UI code. I decided to employ Cockburn use cases with fish,kite,and sea levels (discussed by Martin Fowler in his book 'UML Distilled'). I wrapped Cockburn use cases in static C# objects so that I could test logical conditions against static constants which represented steps in a UI workflow. The idea was that you could read the code and know what it was doing because the wrapped objects and their public contants gave you ENGLISH use cases via namespaces.

Also, I was going to use reflection to pump out error messages that included the described use cases. The idea is that the stack trace could include some UI use case steps IN ENGLISH.... It turned out to be a fun way to achieve a mini,psuedo light-weight Domain Language but without having to write a DSL compiler. So my question is whether or not this is a good way to do this? Has anyone out there ever done something similar?

---

c# example snippets follow

Assume we have some aspx page which has 3 user controls (with lots of clickable stuff). User must click on stuff in one particular user control (possibly making some kind of selection) and then the UI must visually cue the user that the selection was successful. Now, while that item is selected, the user must browse through a gridview to find an item within one of the other user controls and then select something. This sounds like an easy thing to manage but the code can get ugly.

In my case, the user controls all sent event messages which were captured by the main page. This way, the page acted like a central processor of UI events and could keep track of what happens when the user is clicking around.

So, in the main aspx page, we capture the first user control's event.

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


     }
  }

}

So, in the MyCompany.MyApp.Web.UseCases namespace we might have code like this:

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

The workflow use cases embedded in the classes could be inner classes or static methods or enumerations or whatever gives you the cleanest namespace. I can't remember what I did originally but you get the picture.

解决方案

I've never done it, but I've often thought about writing code in UC style, with main success path first and extensions put in as exceptions caught down below. Have not found the excuse to do it - would love to see someone try it and code, even if after the experiment we conclude it's awful, it will still be interesting to try out and refer to.

这篇关于是否可以在代码库中嵌入Cockburn样式文本UML用例提高代码可读性的内容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！