Язык домена: что является лучшим способом выразить?

Question

Один из моих клиентов отправил мне документ с требованием, и, читая этот документ, во мне появилась вспышка. Я начал переписывать этот большой документ, как показано ниже. Как вы думаете, автоматизированный инструмент может генерировать модель данных и правила, пропуская это. Скажем, если какой-либо клиент свяжет свое требование в этом подходе, это позволит каждому лучше понять домен.

Я понимаю, что, так как я знаю, что такое блог и комментарий и сообщение, я могу легко связать его здесь. Однако, если вы отбросите все технические условия своего бизнеса таким образом, будет ли непросто сделать все на одной странице?

• Модель:
  • блог имеет дату
  • блог имеет содержание
  • блог имеет автор
  • блог имеет много комментарии
  • Содержание может иметь изображения
  • содержание может иметь ссылки
  • комментарий имеет блог
  • комментарий имеет имя
  • комментарий имеет электронную почту
  • комментарий может иметь url
  • comme нт имеет Дата
• правила:
  • блог не может быть пустым
  • блог может быть опубликован или разработан
  • блог должен иметь автор
  • блог не может быть удален когда комментарий присутствует
  • блог не может иметь комментарии после 20 дней

Edit:

То, что я действительно пытался придумать здесь - после того, как вы получите документ с требованием, и если вы создадите документ, упомянутый здесь, вы сможете выяснить, на клиента точно ищет.

И еще одно преимущество заключается в том, что вы можете использовать этот документ для дальнейшего совершенствования и разработки проекта. Или даже клиент может напрямую редактировать этот документ вручную, так как теперь он узнал, как мы смотрим его требования (я имею в виду наш язык).

Теперь в некоторой степени эти утверждения можно интерпретировать по-разному.

Например, у меня может быть какой-то инструмент, который будет анализировать операторы и получать информацию, например, если какая-либо модель изменена, изменения правил внесены в этот документ.

Edit:

В настоящее время я пытаюсь следовать этому подходу в сложной модели, как управление заказами, я буду обновлять здесь, что я когда-либо узнал. Между тем, если вас кто-то интересует здесь, они также могут быть связаны со мной.

Answer 1

Для простых случаев, подобных этим, возможно.

В целом, я бы сказал, нет. Если бы это было так просто, как это, это было бы сделано к настоящему времени, и программирование в качестве профессии закончилось бы. Исполнительные администраторы и МСП будут разрабатывать корпоративные системы.

Я думаю, что генерация кода может дать лифт, если вы сами напишите генератор кода и тщательно его поймете. Но в целом я настроен скептически. Я думаю, что сложные проблемы намного сложнее вашего примера.

Случае, которое вы описываете, похоже, будет в сладкой точке Grails или Ruby on Rails или что-то аналогичное Microsoft.

Answer 2

Например, Ruby on Rails предоставляет такой тип домена для конкретного языка. См. Миграции и проверки ActiveRecord.

Он предоставляет некоторые простые части вашей системы, но что-либо сложное должно быть все еще закодировано «вручную».

Answer 3

Учитывая, что все случаи настолько просты, что можно определить ваш язык либо как внутренний DSL, используя язык программирования более высокого уровня, например, рубином или scala, или как внешний dsl с использованием генераторов кода, например. Xtext, MPS, yacc и bison.

Однако, когда результат должен быть общего назначения, согласитесь с duffymo, генераторы или абстракции могут стать очень сложными.

Answer 4

Теперь вы принимаете неправильный подход. Требования должны быть понятны для обеих групп (разработчиков и клиентов) и должны иметь один экземпляр. Поэтому, когда требования меняются только на один, вы должны изменить только один дворец/пиц/информацию. Не несколько документов. Также любой разработчик может попросить у клиента вопрос, поэтому ему нужно будет показать спецификацию (если приложение сложное), и это должна быть спецификация клиента. (Я сказал, когда нет, если).

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

PS Я довольно Shure, что эта спецификация изменится :) блог не может иметь комментарии через 20 дней

PsPs бизнес-логика (ваши правила) являются сложными далеко за пределами вашего простого примера, поэтому возможность связаться с клиентами в любое время (без писем!телефон или VoIP) действительно важно

PSPSPS вы знаете ORM ?? http://en.wikipedia.org/wiki/Object-relational_mapping

Answer 5

См. «Развитие, управляемое поведением», может дать вам некоторые идеи о DSL для спецификаций. Actuallly Я работаю над своей магистерской диссертацией, которая объединит DDD, DSL, BDD и MDSD, чтобы сделать практически то, на что вы нацеливаетесь.

Answer 6

Я понимаю ваше желание иметь более автоматический подход к соблюдению требований в синхронизации с кодом. UML - это хорошо зарекомендовавший себя инструмент для моделирования систем, и существует множество инструментов генерации кода для этого и подобных языков. Однако из тех, кто их использовал, я слышал только ужасные истории.

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