понедельник, 22 августа 2011 г.

С чего начать проектирование программы? Часть 2


Прежде чем следовать дальше, повторим основные тезисы предыдущей статьи:

  1. Любая программа разрабатывается для решения конкретных задач. Эти задачи будем называть полезными функциями или просто функциями.
  2. Прежде чем проектировать архитектуру программы, нужно сначала разработать алгоритм выполнения каждой полезной функции. Такой алгоритм в машиностроении называется технологией или технологическим процессом.
  3. Технологический процесс представляет собой последовательность операций, которая может быть описана либо в текстовом виде в форме варианта использования, либо в форме блок-схемы, flowchart.
  4. Порядок проектирования можно описать в виде такой схемы:

Функция --> Технологический процесс --> Архитектура

Сначала нужно сформулировать полезные функции, которые будет выполнять проектируемая программа. Затем – описать технологический процесс для каждой из них. И только после этого можно проектировать архитектуру.


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

Вернёмся к задаче про датчики и метеостанцию. В предыдущей статье мы остановились на такой схеме технологического процесса:


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

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

Как часто опрашивать порт?

С одной стороны, датчики поставляют нам данные с определённой частотой (например, 10 раз в секунду).

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

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

Чтобы отвязать частоту опроса датчиков от частоты обновления информации на экране, разобъём единый технологический процесс на две части:


Первая часть будет отвечать за опрос датчиков и сохранение полученной информации в базе данных:


Вторая часть будет отвечать за чтение информации из базы и вывод её на экран:


Если мы посмотрим на новые схемы, то заметим, что этап преобразования параметров из одних величин в другие присутствует сразу на обеих схемах. Это сделано не случайно, т.к. конвертация значений может понадобиться как при записи в базу данных (например, когда база хранит температуру в Цельсиях, а датчик измеряет её в Фаренгейтах), так и при выводе информации на экран (например, когда пользователю нужны данные в Фаренгейтах, а в базе они хранятся в виде Цельсиев).

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


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


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

Каждую технологическую цепочку можно реализовать в виде отдельного  потока в одном приложении или даже в виде самостоятельного приложения.

Резюмируя:

  1. Слишком длинные технологические процессы, как правило, распадаются на части из-за того, что к разным участкам этих процессов предъявляются разные требования (например, по частоте выполнения).
  2. Если при проектировании технологического процесса мы столкнулись с проблемой из п. 1, то нужно разделить один процесс на части и связать их между собой при помощи некой сущности, через которую оба новых процесса будут обмениваться данными.