Ошибка мозга в понимании шаблонов проектирования для разработки приложений реального времени

Question

Я поставил себе задачу реализовать приложение MIDI в реальном времени. Как и все другие программы, которые я написал на сегодняшний день, я начал с кодирования. Я реализовал крошечное приложение с графическим интерфейсом (GTK2), которое может контролировать состояние транспорта Jack Audio Connection Kit и его клиентов.

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

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

Во время моего исследования я наткнулся на шаблон Model View Controller, но мне очень трудно не думать о деталях, и я не могу найти основы, на которой можно было бы основываться, не найдя проблем, которые сводят все на нет.

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

Answer 1

В очень общих терминах «разработка программного обеспечения» - это процесс, в котором вы разбиваете проблему под рукой в ​​серии модулей и указываете, какова ответственность каждого модуля, и как каждый модуль должен взаимодействовать с другими модулями (если в все).

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

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

Для каждого подмножества найдите имя, напишите его на чистом листе (по одному на подмножество) и опишите, что модуль делает, более подробно, включая тип данных, с которыми он должен работать и / или обмениваться с другими. Каждый из них является «модульной конструкцией»

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

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

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

См. Также Карты CRC для получения более подробной информации.

Answer 2

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

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

Если ваши технические требования высокого уровня "достаточно хороши, чтобы пользователь был доволен", то вам придется беспокоиться только о технических требованиях низкого уровня - в основном, о том, какой у вас целевой компьютер, ваша целевая ОС и Ваши сторонние библиотеки могут справиться.

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

Наконец, большинство программ для работы в реальном времени написано в виде цикла, примерно так:

while( program_running )
{
  // This period needs to be long enough for you to do your work
  //  but short enough that your user doesn't think your program
  //  is choppy. Anything better than 50 Hz is usually good enough
  //  for an application with a human interface.
  wait_for_short_period() 
  check_interfaces_for_new_data()
  update_model() // or state machine
  update_outbound_interface() // the speaker, monitor, whatever
}

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

Answer 3

Одним из способов было бы обсудить ваши требования и очень кратко изобразить дизайн с кем-то, кто знаком с designpattern и проектированием программного обеспечения. Во время этого процесса вы могли бы обсудить концепции прикладного designpattern.