Можно ли внедрить текстовое содержимое UML Use Case в стиле Кокберна в базу кода для улучшения читабельности кода?
Я писал какой-то сложный код пользовательского интерфейса. Я решил использовать варианты использования Кокберна с уровнями рыбы, воздушного змея и моря (обсуждается Мартином Фаулером в его книге «UML Distilled»). Я обернул варианты использования Cockburn статическими объектами C #, чтобы можно было проверить логические условия на соответствие статическим константам, представляющим шаги в рабочем процессе пользовательского интерфейса. Идея состояла в том, чтобы вы могли прочитать код и узнать, что он делает, потому что обернутые объекты и их открытые константы дали вам АНГЛИЙСКИЙ вариант использования через пространства имен.
Кроме того, я собирался использовать отражение, чтобы выкачать сообщения об ошибках, которые включали описанные варианты использования. Идея состоит в том, что трассировка стека может включать в себя некоторые этапы использования пользовательского интерфейса НА АНГЛИЙСКОМ ЯЗЫКЕ .... Это оказалось забавным способом создания мини-легкого доменного языка psuedo, но без написания DSL-компилятора. Итак, мой вопрос, является ли это хорошим способом сделать это? Кто-нибудь когда-нибудь делал что-то подобное?
c# example snippets follow
Предположим, у нас есть страница aspx, которая имеет 3 пользовательских элемента управления (с множеством интерактивных элементов). Пользователь должен щелкнуть по элементу в одном конкретном пользовательском элементе управления (возможно, делая какой-то выбор), а затем пользовательский интерфейс должен визуально сообщить пользователю, что выбор был успешным. Теперь, пока выбран этот элемент, пользователь должен просмотреть сетку, чтобы найти элемент в одном из других пользовательских элементов управления, а затем выбрать что-то. Это звучит как простая вещь для управления, но код может стать ужасным.
В моем случае пользователь контролирует все отправленные сообщения о событиях, которые были захвачены главной страницей. Таким образом, страница действовала как центральный процессор событий пользовательского интерфейса и могла отслеживать, что происходит, когда пользователь нажимает кнопку мыши.
Итак, на главной странице 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...
Варианты использования рабочего процесса, встроенные в классы, могут быть внутренними классами или статическими методами, перечислениями или чем угодно, что дает вам самое чистое пространство имен. Я не могу вспомнить, что я делал изначально, но вы поняли.