Лекции - Системы реального времени
Подождите немного. Документ загружается.
17 КРИТЕРИИ НАЗНАЧЕНИЯ ПРИОРИТЕТОВ ЗАДАЧАМ
Критерии назначения приоритетов задачам помогают выявить высоко- и
низкоприоритетные задачи. Часто приоритетности задач уделяет ся внимание
только на поздних стадиях цикла разработки. Главная причина, по которой мы
относим эти вопросы к этапу разбиения на задачи, состоит в желании выявить
критические по времени и некритические, но связанные с большим объемом
вычислений объекты, которые следует рассматривать как отдельные задачи.
Приоритеты для большинства задач определяются методом планирования в
реальном времени.
Критической по времени называется задача, которая обязана
завершиться к точно установленному сроку. Такая задача должна выполняться с
высоким приоритетом. Высокоприоритетные критические по времени задачи
необходимы в большинстве приложений реального времени.
Рассмотрим ситуацию, когда после исполнения критического по времени
объекта задействуется объект, некритический по времени.
Можно было бы объединить эти объекты в соответствии с критерием
последовательной группировки. Но, чтобы гарантировать быстрое
обслуживание критического по времени объекта, предпочтительнее выделить
его в самостоятельную высокоприоритетную задачу. Такая ситуация типична
для асинхронных задач ввода/вывода, управляемого прерываниями, когда
обработка прерывания критична по времени.
В качестве примера рассмотрим объект Контроль Температуры в Печи.
Если температура превышает 100°С, то печь следует выключить. Этот объект
отоб р аж ае т с я н а вы с окоп ри о ри т ет н ую за дачу, котор ая дол жн а у сп е ть
завершиться в течение жестко определенного времени, в противном случае
изделие, находящееся в печи, сгорит. Другие разновидности критических по
времени задач – управляющие задачи и асинхронные задачи интерфейса с
устройствами ввода/вывода. Управляющая задача исполняет некоторую
диаграмму состояний и обязана работать с высоким приоритетом, поскольку
переходы состояний должны производиться быстро. Асинхронной задаче в вода/
31
вывода следует иметь высокий приоритет, чтобы успевать обслуживать
прерывания, иначе есть риск пропустить одно из них.
Некритические по времени расчетные задачи. Некритическая по времени
расчетная задача требует значительных ресурсов проце ссора, но может
выполняться с низким приоритетом. Идея о низкоприоритетных задачах со
сложными вычислениями, которые способны действовать в фоновом режиме и
вытесняться высокоприоритетными задачами, появилась еще в ранних системах
мультипрограммирования и обычно поддерживается современными ОС.
Алгоритм, требующий больших вычислительных ресурсов, не всегда
можно отобразить на низкоприоритетную задачу. Приоритет его зависит от
приложения: бывают ситуации, когда расчетный алгоритм является
критическим по времени и должен выполняться с высоким приоритетом.
32
18 ОСНОВЫ РАЗРАБОТКИ АРХИТЕКТУРЫ ЗАДАЧ
Критерии разбиения на задачи можно применять к аналитической модели
следующим образом. В каждом случае нужно сначала решить, будет ли объект
из аналитической модели отображаться на активный или пассивный объект
проектной модели:
• задачи интерфейса с устройством. Начните с объектов интерфейса
устройств, взаимодействующих с внешним миром. П роанализируйте, должен
объект быть асинхронным, периодическим или пассивным интерфейсом
устройства ввода/вывода, монитором ресурсов или темпорально
сгруппированной периодической задачей ввода/вывода;
• управляющие задачи. Рассмотрите все зависящие от состояния управляющие
объекты. Отобразите их на управляющие задачи. Каждый объект, который
выполняет действие (операцию), инициируемое определенной управляющей
задачей, потенциально можно объединить с этой задачей, применив критерий
группировки по управлению. Каждую деятельность, которая начинается и
завершается управляющей задачей, следует оформить в виде отдельной
задачи.
• Такой же подход применим и к нескольким однотипным управляющим
объектам, зависящим от состояния. Проверьте, можно ли отобразить каждый
объект н а отдельную задачу и следует ли применять инверсию задач. Это
особенно важно в случаях, когда есть большое число однотипных задач, и,
следовательно, накладные расходы на контекстное п ереключение нельзя
игнорировать;
периодические задачи. Проанализируйте внутренние периодические
деятельности, которые оформляются как периодические задачи. Выясните,
есть ли среди них такие, которые запускаются одним и тем же событием. В
этом случае их можно связать в одну задачу, применив критерий
темпоральной группировки. Возможно, удастся т акже задействовать
критерий последовательной группировки для объединения ряда других задач;
33
• другие внутренние задачи. Для каждой внутренней задачи, активизируемой
внутренним событием, проверьте, нет ли среди соседних с ней задач на
диаграмме параллельной кооперации таких, которые можно объединить на
основе различных критериев группировки: последовательной, темпоральной
или по взаимному исключению.
• Поскольку задача может подпадать сразу под несколько критериев разбиения,
то решающи м становится первый из тех, который удалось усп ешно
применить. Последующие критерии, которым удовлетворяет эта задача,
должны либо подтвердить правильность решения, либо свидетельствовать о
необходимости его пересмотра. Рассмотрим, например, объект интерфейса
устройства, который был структурирован как пассивная задача вывода, но
при этом он т акже активизируется управляющим объектом. Если
оказывается, что операци я вывода всегда выполняется синхронно при
переходе состояний, то первоначальное решение, вероятно, неправильно, так
как объект интерфейса устройства можно объединить с управляющим
объектом, применив группировку по управлению.
После разбиения системы на параллельные задачи рисуется начальная
диаграмма параллельной кооперации, на которой представлены все задачи.
Интерфейсы задач на ней все еще показываются в виде простых сообщений, как
на диаграммах кооперации из аналитической модели.
34
19 СПЕЦИФИКАЦИЯ ПОВЕДЕНИЯ ЗАДАЧИ
Спецификация поведения задач и (СПЗ) о пис ывает ее интерфейс,
структуру, временные характеристики, относительный приоритет, логику
упорядочения событий и обнаруживаемые ошибки. Интерфейс задачи – это
способ ее взаимодействия с другими задачами. Структура говорит о том, как
данная задача появилась (посредством какого критерия разбиения). Временные
характеристики – это частота активизации и ожидаемое время выполнения.
Полученная информация используется для планирования в реальном времени.
СПЗ прилагается к описанию архитектуры задач. В процессе разбиения
на задачи в СПЗ заносится информация о входных и выходных данных задачи.
Часть СПЗ составля ется позже, на этапе детального проектирования
программы.
СПЗ определяется следующим образом:
Интерфейс задачи. Сюда должны включаться:
• входные и выходные сообщения – для каждого сообщения необходимо
указать тип интерфейса (слабо связанный, сильно связанный с ответом,
сильно связанный без ответа), имя и параметры;
• события (входные и выходные) – необходимо указать имя и тип события
(внешнее, внутреннее, таймера);
• внешние входы и выходы – определяются входные данные из внешней
среды и выходная информация, выводимая во внешнюю среду;
• используемые пассивные объекты.
4. Информация о структуре задачи. Включает в себя:
• критерий, примененный для выделения этой задачи;
• объекты из аналитической модели, отображенные на эту задачу.
5. Временные характеристики:
• частота активизации. Для периодической задачи – ее период Т
i
для
асинхронной задачи - ожидаемая средняя и максимальная частота
активизации асинхронными событиями;
35
• ожидаемое время С
i
выполнения задачи. Если есть несколько путей
выполнения, то оценка времени для основных из них.
6. Относительный приоритет задачи. Задаче назначается приоритет
относительно других исполняемых в системе задач.
7. Ошибки, обнаруживаемые задачей. Описывают ся ошибки, которые могут
встретиться при исполнении задачи.
8. Логика упорядочения событий. Рассматриваются реакции задачи на каждое
сообщение или событие и то, какая выходная информация при этом
генерируется. Данный аспект поведения задачи определяется на этапе
детального проектирования программы.
36
20 ПРОЕКТИРОВАНИЕ ОПЕРАЦИЙ КЛАССОВ
На этом этапе проектируются скрывающие информацию классы, из
которых создаются экземпляры пассивных объектов. Первоначально классы
определяются на этапе построения аналитической модели в ходе разбиения
системы на объекты и классы. Класс применяет сокрытие информации для
решения различных вопросов, связанных со статической структурой, например
сокрытия информации об устройстве или абстрагирования данных. Операции
класса можно вывести как из статической, так и из динамической модели.
Хотя для отражения операций классов предназначена статическая модель,
их проще выявить на основе анализа динамической модели, прежде всего из
диаграммы кооперации. Это обусловлено тем, что в динамической модели
отражен обмен сообщениями между объектами, а следовательно, и операции
объекта-получателя. Передача сообщений между пассивными объектами – не
что иное, как вызов операции одного объекта из операции другого объекта.
Проектирование операций классов на основе модели взаимодействия.
Воспользуемся моделью взаимодействия объектов для выявления операций
классов. Для этой цели годится как диаграмма кооперации, так и диаграмма
последовательности. Операции классов определяются путем рассмотрения того,
как объект данного класса взаимодействует с другими объектами, поскольку
взаимодействие двух объектов состоит в том, что один из них вызывает
операцию другого. При проектировании операций классов мы будем применять
в основном диаграммы кооперации.
Рассматривая два взаимодействующих объекта, необходимо понять, чьи
операции вызываются. Обычно для этого недостаточно диаграммы классов из
статической модели, так как на ней показаны только статические отношения
между классами. С другой с тороны, из динамической модели видно
направление передачи сообщений от одного объекта к другому. Если
спроецировать объекты на последовательную программу, то окажется, что
объект-отправитель вызывает операцию объекта-получателя. Следовательно,
сообщению ставится в соотве тствие вызов операци и. Имя сообщен ия
37
отображается на имя операции, а параметры сообщения – на параметры
операции.
Операции объекта допустимо определить непосредственно из диаграммы
взаимодействия, на которой этот объект присутствует. В аналитической модели
акцент ставится на той информации, которой обмениваются объекты, а не на
точном с ин т а кси с е о п е ра ц ии . П о э том у им я с о об щ ен и я н а ди а г ра м м е
кооперации может быть существительным (отражающим тип передаваемых
данных) или глаголом (описывающим саму выполняемую операцию).
В модели проектирования специфицируются операции классов. Если имя
сообщения было существительным, необходимо определить операцию объекта,
который получит поименованную информацию. Если же имя сообщения было
глаголом, оно и становится именем операции. Имя, данное операции в
проектной модели, должно отражать ее назначение в классе.
Важно также выяснить, у каких операций есть входные и выходные
параметры. В аналитической модели все сообщения на диаграмме кооперации
изображают ся в виде простых сообщений, посылаемых одним объектом
другому. В некоторых случаях простое сообщение – это ответ на полученное
сообщение. На диаграммах кооперации из проектной модели сообщения,
вызывающие операции, изображаются как синхронные. Те простые сообщения,
представленные в аналитической модели, которые соответствуют данным,
возвращенным операцией, то есть ответам, отображаются на выходные
параметры операции.
После определения операции на основе диаграммы кооперации она
изображается на статической модели вместе с классом, который ее содержит.
Очень удобно одновременно выявлять операции из диаграмм кооперации и
изображать их на диаграммах классов.
Проектирование операций кл ассов на основе конечного автомата.
Операции классов можно также вывести из диаграммы состояний. На ней
представлены действия и деятельности, инициируемые в ре зультате перехода
состояний. Действия, как правило, отображаются на операции класса. На
диаграммах состояний показаны все зависящие от состояния действия и
38
деятельности. Если действия выполняются пассивными классами, то они
выводятся из диаграммы состояний.
Действия и деятельности должны быть изображены также на диаграмме
кооперации или последовательности. Поскольку на этих диаграммах обычно
показываются сценарии прохождения прецедентов (конкретные
последовательно сти взаимодействий между объектами), то редко
встречающиеся альтернативы (к примеру, обработка исключений) часто
пропускаются. Таким образом, хотя любое действие должно быть отражено на
консолидированных диаграммах кооперации, на какой-то отдельной диаграмме,
относящейся к конкретному прецеденту, его может и не быть. На диаграмме
состояний должны присутствовать все зависящие от состояния действия и
деятельности.
Проектирование операций классов на основе статической модели.
Проектировать операции классов на основе диаграмм классов из статической
модели тоже можно, о собенно для сущностных классов. Стандартными
являются операции создать, читать, обновить, удалить. Но зачастую состав
операций легко адаптировать под нужды конкретного класс а абстрагирования
данных, определив, какие сервисы он должен предоставлять. Здесь объекты,
вызывающие операции пассивных объектов, в основном тоже считаются
пассивными, хотя могут быть и активными.
39
21 ТЕОРИЯ ПЛАНИРОВАНИЯ В РЕАЛЬНОМ ВРЕМЕНИ
Анализ производительно сти про ект а о собенно важен для систем
реального времени. Если такая система не справляется со своими задачами в
течение отведенного интервала, последствия могут быть катастрофическими.
Количественный анализ про екта системы реального времени позволяет на
ранних этапах выявить потенциальные проблемы с производительностью.
Анализу подвергается проект ПО, концептуально исполняемый на данной
аппарат ной ко нфигурации с рассчитанной вн еш ней раб очей нагрузкой.
Обнаружив вероятные проблемы, легко рассмотреть альтернативные подходы к
проектированию или иную конфигурацию аппаратуры.
Анализ производительно сти про екта ПО основывается на теории
планирования в реальном времени. Этот метод прекрасно работает для систем
реа льного времени, которые должны выдерживать жесткие временные
ограничения. Он позволяет определить, будут ли выполнены наложенные
ограничения.
В теории планирования в реальном времени рассматриваются вопросы
приоритетного планирования параллельных задач с жесткими временными
ограничениями. В частности, она позволяет предсказать, будет ли группа задач,
для каждой из которых потребление ресурсов ЦП известно, удовлетворять этим
ограничениям. В теории предполагается использование алгоритма
приоритетного планирования с вытеснением.
По мере своего развития теория планирования в реальном времени
применялась к все более сложным задачам, в числе которых планирование
независимых периодических задач, планирование в ситуации, когда есть и
периодические, и апериодические (асинхронные) задачи, а также планирование
задач, требующих синхронизации.
Планирование периодических задач. Изначально алгоритмы
планирован ия в реальном времен и разрабатывались для независимых
периодиче ских задач, то есть таких периодиче ских задач, которые не
40