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

Один из вариантов решения этих заморочек состоит в отказе от представления, что задачки АРМВС производятся поочередно, т. е. в каждый момент времени работает лишь один исполнитель. Будем считать, что для заслуги какой-нибудь цели может сразу работать коллектив задач. Слово «коллектив» подчеркивает, что меж задачками имеются каналы оперативной связи. Таковой подход оправдан к тому же тем, что некие из задач, к примеру, мониторинг, разбиваются на несколько частей, которые описываются логически независящими методами и должны работать в настоящем масштабе времени, и набор этих частей может изменяться зависимо от поставленной цели. Механизм, управляющий как коллективом задач, так и коллективом частей в рамках одной задачки может быть (и должен быть) одним и этим же.

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

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

Совокупное поведение коллектива таковых действий нельзя обрисовать строго упорядоченной во времени последовательностью действий, так как состояние, в каком находится один процесс, никак не зависит от состояния остальных действий. Такие процессы именуют асинхронными. Конкретно асинхронные процессы более правильно моделируют хотимое поведение АРМВС, но проектирование таковой модели в определениях поочередного программирования встречает неодолимые трудности. Разумеется, что организация взаимодействия асинхронных действий может быть выполнена лишь при помощи средств, поставляемых наружной средой. В качестве таковой наружной среды выступает многозадачная операционная система либо многозадачная операционная оболочка.

Принципиальное значение в этих критериях приобретает выбор технологии программирования.

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

Разглядим более соответствующий вариант дизайна программного обеспечения АРМВС в виде встроенной прикладной системы, функционирующей в однозадачной операционной среде MS-DOS. Основываясь на этом выборе, проанализируем индивидуальности реализации отдельных функций АРМВС.