Шаблон проектирования “минисценарий с проверкой противоречий”

[sshmakov]

Вы в начале привели таблицы, из которых явным образом следует, что в ТЗ есть противоречие. Почему этих таблиц нет в ТЗ?

[dim2r]

даже если бы были, — ТЗ не программа, оно само не проверяет противоречия

[sshmakov]

Вы тоже, но противоречие нашли.
Хотя я понимаю, откуда ноги растут — у вас, скорее всего, составляются ТЗ на доработку, а документа, содержащего актуальное описание функциональности, с которым можно сверяться при подготовке ТЗ — нет. Так?

Если что, я отвечаю на ваш же вопрос в статье:

3. Как вести знания о предметной области и как формулировать ТЗ, чтобы не было противоречий?

[dim2r]

составляются ТЗ на доработку

Так и есть.

Система мутирует много лет и меняются законы для бизнеса, поэтому на ТЗ, которому больше пары лет — уже никто не смотрит.

[third112]

ИМХО причина обсуждаемой ошибки: естественное желание сделать лаконичный код. Классическое решение согласно принципам защитного программирования: избыточность.

case doctype of
1: case clienttype of
    1: do_something1;
    2:  do_something2;
    3:  do_something3;
    else error (unknownClienttype, clienttype);
    end;	
2: case clienttype of
    1: …
    2:  …
    3:  …
    else error (unknownClienttype, clienttype);
    end;	
3: case clienttype of
    1: …
    2:  …
    3:  …
    else error (unknownClienttype, clienttype);
    end;	
 else error (unknownDoctype, doctype);
end;

Фактически это та же матрица сочетаний, но развернутая в линию кода программы. Функция error выводит характер ошибки и значение переменной, ее вызвавшее. В случае необходимости нетрудно написать генератор, который сделает шаблон подобного кода.
Для лучшей ориентации в коде значения нужно заменить на константы с осмысленными именами:

const ORGANIZATION = 1;
…
case clienttype of
    ORGANIZATION: do_something1;

Вместо многоточий стоит поставить комментарии:

{ToDo}

При возможности лучше сразу писать целевой код, а не создавать внекодовую матрицу, т.к. при переносе из нее в код возможны опечатки. А для тестирования и документации этот код автоматически с помощью несложного конвертора можно превратить в матрицу, нпр., в Excel.

[dim2r]

Поддерживаю данный подход!
Только, если атрибута 3, то это уже трехмерная матрица. Если их будет штук 40, то полное сочетание в case операторе будет монстром. При добавлении нового атрибута надо будет еще во все места case оператора дописывать еще один уровень вложенности.

Плюс Вы не поняли еще одну фишку моего подхода — дополнительные действия с минисценариями. Их можно анализировать без внесения изменения в базу данных. Например, можно делать легкое регрес-тестирование или прогонять по всей базе не боясь чего-то изменить.

[third112]

Ничего не мешает сделать подобный код и для 40 атрибутов. 40 уровней для вложенных case, конечно, будет очень объемным. И конечно его надо генерировать с помощью несложной программы или скрипта, а не писать руками, чтобы не ошибиться. На каждой вершине стоит перечислить значения атрибутов:

do_something1; // clienttype=ORGANIZATION doctype=...

Но ИМХО ничего страшного — главное уверенность, что это будет верно работать и легко модифицироваться!

[third112]

PS

еще одну фишку моего подхода — дополнительные действия с минисценариями

Ok. Я предложил альтернативное решение. Как часто бывает везде свои ++ / --.

[third112]

PPS Прикинул, что 40 уровней может быть многовато для моего предложения…

[dim2r]

Я тоже подход с case-ом когда то пытался проанализировать. Это похоже на промежуточный вариант между тем, что пишут в ТЗ и мат. логикой, которая основана математических конструкциях.

Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.

[third112]

Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.

Да, только я использовал не свой язык, а Delphi. Вы отметили важный принципиальный момент: чем больше сходство кода с ТЗ — тем он убедительнее.

[third112]

Не та ветка…

[vasiliy404alfertev]

Мне эта проблема напомнила про Drools. www.youtube.com/watch?v=GvN9W67Bscs&t=1s
Когда бизнес-логика усложняется, а ТЗ является просто коллекцией утверждений, требуется экспертная система для проверки противоречий.

[dim2r]

Спасибо за ссылку,
Надо будет попробовать реализовать пример из ролика на своем движке

[velvetcat]

Имхо у Вас в самом изначальном примере дублирование знаний (действие можно привязать к типу лица, а можно — к типу договора), и отсюда все проблемы. Атрибуты по-возможности должны быть ортогональны.

[dim2r]

Это упрощенный пример для демонстрации, как происходит запутывание кода изза тусовки кадров.

[sshmakov]

Во втором требовании опечатка — судя по коду и дальнейшим рассуждениям там должно быть «юрлица»

[vanxant]

Ударим некропостом!..)
Все ссылки и идеи в статье есть, но главный вывод не сформулирован. Все бизнес правила должны лежать во внешнем хранилище и вообще не дублироваться в коде собственно программы. Программист должен вместо пачки условий дернуть интерпретатор, который сходит в хранилище и скажет «делай три раза ку». Поменялись правила в хранилище — изменилась бизнес-логика всего подключенного софта, без перекомпиляции.

[dim2r]

Вашими устами да мед пить.
(не я минуснул, если что...)

В большом проекте не раз видел, как крутые разработчики ипытывали разные эмоции.
Первая неделя — энтузиазм.
Вторая неделя — озабоченность.
Третья неделя — иллюзия, что вот вот и решу задачу, стоит только попотеть.
Четвертая неделя — отчаяние, но надежда еще есть.
Пятая неделя — сплошные возмущения, но дело уже сдвинулось на миллиметр.
Шестая неделя — начал понимать все извращение, но психика уже покалечена.
…

[dim2r]

ну так, продемонстрируйте решение означенных проблем