- •2. Ядра и операционные системы реального времени
- •2.1. Задачи, процессы, потоки
- •2.2. Основные свойства задач
- •2.3. Планирование задач
- •2.4. Синхронизация задач
- •2.5. Тестирование
- •2.6. Можно ли обойтись без ОС РВ?
- •3. Обзор некоторых операционных систем реального времени
- •3.1. Linux реального времени
- •3.2. Операционные системы реального времени и Windows
- •3.3. Операционная система QNX
- •3.4. Проект Neutrino
- •4.1. Организация промышленных систем
- •4.2. Аппаратная архитектура
- •4.3. Стандарты шин
- •4.4. Технологии VME и PCI
- •4.5. Мезонинные технологии
- •4.6. Полевые системы
- •4.7. Программное обеспечение промышленных систем
- •4.8. Управление производством
- •Часть 2. ПРОЕКТИРОВАНИЕ СРВ
- •5. UML проектирование систем реального времени
- •5.1. Объектно-ориентированные методы и UML
- •5.2. Метод и нотация
- •5.3. Системы и приложения реального времени
- •6. Обзор нотации UML
- •6.1. Диаграммы UML
- •6.2. Диаграммы прецедентов
- •6.3. Нотация UML для классов и объектов
- •6.4. Диаграммы классов
- •6.5. Диаграммы взаимодействия
- •6.6. Диаграммы состояний
- •6.7. Пакеты
- •6.8. Диаграммы параллельной кооперации
- •6.9. Диаграммы развертывания
- •6.10. Механизмы расширения UML
- •7.1. Среды для параллельной обработки
- •7.2. Поддержка исполнения в мультипрограммной и мультипроцессорной средах
- •7.3. Планирование задач
- •7.4. Вопросы ввода/вывода в операционной системе
- •7.6. Технология World Wide Web
- •7.7. Сервисы распределенных операционных систем
- •7.8. ПО промежуточного слоя
- •7.9. Стандарт CORBA
- •7.10. Другие компонентные технологии
- •7.11. Системы обработки транзакций
- •8. Разбиение на задачи
- •8.1. Вопросы разбиения на параллельные задачи
- •8.2. Категории критериев разбиения на задачи
- •8.3. Критерии выделения задач ввода/вывода
- •8.4. Критерии выделения внутренних задач
- •8.5. Критерии назначения приоритетов задачам
- •8.6. Критерии группировки задач
- •8.7. Пересмотр проекта путем инверсии задач
- •8.8. Разработка архитектуры задач
- •8.9. Коммуникации между задачами и синхронизация
- •8.10. Спецификация поведения задачи
- •9. Проектирование классов
- •9.1. Проектирование классов, скрывающих информацию
- •9.2. Проектирование операций классов
- •9.3. Классы абстрагирования данных
- •9.4. Классы интерфейса устройства
- •9.5. Классы, зависящие от состояния
- •9.6. Классы, скрывающие алгоритмы
- •9.7. Классы интерфейса пользователя
- •9.10. Внутренние программные классы
- •9.11. Применение наследования при проектировании
- •9.12. Примеры наследования
- •9.13. Спецификация интерфейса класса
- •10. Детальное проектирование ПО
- •10.1. Проектирование составных задач
- •10.2. Синхронизация доступа к классам
- •10.4. Логика упорядочения событий
- •11.1. Теория планирования в реальном времени
- •11.2. Развитие теории планирования в реальном времени
- •11.5. Пример анализа производительности с помощью анализа последовательности событий
- •11.6. Пример анализа производительности с применением теории планирования в реальном времени
- •11.8. Пересмотр проекта
- •11.9. Оценка и измерение параметров производительности
- •12. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
210 |
Рис.9.4. Пример класса интерфейса устройства вывода:
б– проектная модель (диаграмма кооперации);
в– проектная модель (диаграмма классов)
9.5.Классы, зависящие от состояния
Класс, зависящий от состояния, инкапсулирует информацию,
которая представлена на диаграмме состояний. На этапе проектиро- вания классов диаграмма состояний, исполняемая зависящим от со- стояния объектом, отображается на таблицу переходов состояний. Таким образом, зависящий от состояния класс скрывает устройство этой таблицы и поддерживает текущее состояния объекта.
Зависящий от состояния класс предоставляет операции для дос- тупа к таблице переходов состояний и для ее изменения. В частности, проектируются операции для обработки входных событий, вызы-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
211 |
вающих переходы состояний. Например, можно задать отдельную операцию для каждого такого события. Это означает, что зависящий от состояния класс проектируется специально для конкретной диа- граммы состояний. Хотелось бы, однако, чтобы подобные классы бы- ли более обобщенными и могли использоваться повторно.
Обобщенный зависящий от состояния класс по-прежнему будет скрывать устройство таблицы переходов, но в нем имеется всего две операции: обработатьСобытие и текущееСостояние. Операция об-
работатьСобытие вызывается, когда поступает новое событие, ко- торое и передается в качестве входного параметра. Операция теку- щееСостояние (она может отсутствовать) возвращает состояние ко- нечного автомата. Такая операция нужна лишь в тех приложениях, где клиентам необходимо знать текущее состояние зависящего от со- стояния класса. Вот сигнатуры операций:
обработатьСобытие (событие) текущееСостояние ( ) : Состояние
Операция обработатьСобытие просматривает таблицу перехо- дов состояний с целью определить, что нужно сделать с новым собы- тием, принимая во внимание текущее состояние и заданные в таблице условия. Таблица показывает, в какое состояние следует перейти (ес- ли это необходимо) и какие действия одновременно выполнить. Та- ким образом, операции остается изменить состояние объекта и вы- полнить действия, вызвав операции тех или иных объектов.
Другой, более гибкий подход к проектированию операции обра- ботатьСобытие состоит в том, чтобы не выполнять действие само- стоятельно, а вернуть его в выходном параметре. Тогда сигнатура принимает вид:
обработатьСобытие (in событие, out действие)
Такой зависящий от состояния класс оказывается достаточно общим для инкапсуляции любой таблицы переходов. Устройство
таблицы зависит от приложения и определяется в момент создания или инициализации объекта класса. Пример зависящего от состояния класса в системе круиз-контроля – это класс Управление Калибров- кой. На диаграмме кооперации из аналитической модели (рис.9.5а)
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
212 |
показан объект Управление Калибровкой, исполняющий диаграмму состояния на рис.9.56.
Рис.9.5. Пример зависящего от состояния управляющего класса:
а – аналитическая модель (диаграмма кооперации); б – аналитическая модель (диаграмма состояний); в – проектная модель (диаграмма кооперации); г – про- ектная модель (диаграмма классов)
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
213 |
Объект Управление Калибровкой получает события Начать Ка-
либровку и Прекратить Калибровку от двух объектов Интерфейс Кнопки Калибровки. Если получено сообщение Начать Калибровку
(событие Ca1.1), то диаграмма состояний (рис.9.56) показывает, что должно быть выполнено действие Начать (Са1.2). В результате объ-
ект Управление Калибровкой посылает сообщение Начать объекту Калибровочная Константа, который выполняет действие. Если же получено сообщение Прекратить Калибровку (событие Са2.1), то из диаграммы состояний следует, что нужно выполнить действие Пре-
кратить (Са2.2). Теперь объект Управление Калибровкой отправляет сообщение Прекратить объекту Калибровочная Константа.
В проектной модели (рис.9.5в и 9.5г) сообщения Начать Калиб-
ровку и Прекратить Калибровку отображаются на вызовы операции
обработать Событие класса Управление Калибровкой, которой в ка-
честве входного параметра передаются соответственно события нача-
лоКалибровки и прекраще-ниеКалибровки. Действия начать и прекра-
тить превращаются в операции объекта абстрагирования данных Ка-
либровочная Константа и вызываются операцией обработатьСо- бытие объекта Управление Калибровкой.
9.6. Классы, скрывающие алгоритмы
Такие классы скрывают алгоритмы, применяемые в предметной области; они типичны в системах реального времени, а также в науч- ных и инженерных приложениях. Как правило, такой класс скрывает не только алгоритм, но и локальные данные, необходимые для его ра- боты.
Пример скрывающего алгоритм класса – это класс Средняя Ско- рость (рис.9.6), который скрывает алгоритм вычисления средней скорости автомобиля в системе круиз-контроля и мониторинга. В нем
есть операция сброс для обнуления внутренних данных и операция вычислить для расчета средней скорости движения. Обе эти опера-
ции вызывают операцию вывести объекта Интерфейс Маршрутного Дисплея, передавая среднюю Скорость в качестве параметра (рис.9.6б). Диаграмма класса изображена на рис.9.6в.
www.pdffactory.com