- •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. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
202 |
должны присутствовать все зависящие от состояния действия и дея- тельности.
9.2.3. Проектирование операций классов на основе статической модели. Проектировать операции классов на основе диаграмм классов из статической модели тоже можно, особенно для сущностных клас- сов. Стандартными являются операции создать, читать, обновить, удалить. Но зачастую состав операций легко адаптировать под нужды конкретного класса абстрагирования данных, определив, какие сер- висы он должен предоставлять. Ниже это будет проиллюстрировано на примерах. Здесь объекты, вызывающие операции пассивных объ- ектов, в основном тоже считаются пассивными, хотя могут быть и ак- тивными.
9.3. Классы абстрагирования данных
Каждый сущностный класс из аналитической модели, который инкапсулирует данные, проектируется как класс абстрагирования данных. Сущностный класс хранит данные и предоставляет операции для доступа к ним – операции чтения и записи. Класс абстрагирова- ния данных используется для инкапсуляции структуры данных, то есть сокрытия деталей ее внутреннего представления. Операции про- ектируются как процедуры иди функции доступа, внутреннее устрой- ство которых также скрыто.
Информация об атрибутах класса абстрагирования данных должна уже присутствовать в статической модели предметной облас- ти. Операции такого класса определяются путем рассмотрения тех сервисов, которые нужны клиентским объектам для опосредованного доступа к данным. Это можно сделать, проанализировав способы ис- пользования объекта абстрагирования данных в модели кооперации.
9.3.1. Пример класса абстрагирования данных. Для знакомства с классами абстрагирования данных рассмотрим диаграмму коопера- ции из аналитической модели (рис.9.2а), состоящую из двух объек- тов, которым нужен доступ к объекту Наличные Банкомата. Атрибу- ты данного объекта приведены в статической модели: это количество пяти-, десяти- и двадцатидолларовых купюр в устройстве выдачи на- личных. Таким образом, в объекте должны быть внутренние пере- менные, содержащие соответствующие счетчики купюр. Таким обра- зом, мы проектируем класс Наличные Банкомата с четырьмя атрибу-
тами: имеющаясяСумма, пятидолларовыеКупюры, десятидол-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
203 |
ларовые Купюры, двадцатидолларовыеКупюры. Начальное значение всех атрибутов установлено в ноль.
Необходимы сведения о том, какие сообщения посылаются объ- екту Наличные Банкомата и какова последовательность их отправки. Так, из аналитической модели явствует, что, когда объект Наличные Банкомата получает сообщение Снимаемая со Счета Сумма от объ- екта Интерфейс Устройства Выдачи Наличных, он должен вычис-
лить, сколько купюр каждого достоинства выдать. В аналитической
модели эта информация посылается в ответном сообщении Ответ о Выдаче Наличных.
Объект Наличные Банкомата получает также сообщение от объекта Интерфейс Оператора. Человек-оператор пополняет запас наличных в банкомате купюрами разного достоинства, а соответст- вующая информация передается объекту Наличные Банкомата. До- бавив наличные, оператор уведомляет банкомат с помощью объекта
Интерфейс Оператора, который посылает сообщение Добавлены Наличные объекту Наличные Банкомата (рис.9.2а).
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
204 |
Рис.9.2. Пример класса абстрагирования данных:
а – аналитическая модель (диаграмма кооперации); б – проектная модель (диа- грамма кооперации); в – проектная модель (диаграмма классов)
Теперь мы можем специфицировать операции класса Наличные Банкомата так, как показано на диаграмме кооперации проектной модели на рис.9.26. Нужны две операции: добавитьНаличные и вы-
датьНаличные. У операции выдатьНаличные один входной пара- метр: суммаКВыдаче – и три выходных: выдатьПяти- долларовыхКупюр, выдатьДесятидолларовыхКупюр, вы-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
205 |
датьДвадцатидолларовыхКупюр. У операции добавитьНа-личные три входных параметра: добавленоПятидолларовых Купюр, добавле- ноДесятидолларовыхКупюр и добавлено ДвадцатидолларовыхКупюр.
Вот как специфицируются операции:
выдатьНаличные(in суммаКВыдаче, out выдать ПятидолларовыхКупюр,
out выдатьДесятидолларовыхКупюр, out выдатьДвадцатидолларовыхКупюр)
добавитьНаличные(in добавлено ПятидолларовыхКупюр,
in добавленоДесятидолларовыхКупюр, in добавленоДвадцатидолларовыхКупюр)
Диаграмма классов изображена на рис.9.2в.
Объекты этого класса поддерживают инвариант: общая сумма наличных в банкомате должна равняться суммарному значению дос- тоинств всех купюр:
имеющаясяСумма = 5 * пятидолларовыеКупюры + . + 10 * десятидолларовыеКупюры + 20 * двадцатидолларовыеКупюры
Недостаток наличных – это ошибка, которую нужно распозна- вать. Обычно такие ошибки обрабатываются как исключения.
9.4. Классы интерфейса устройства
Одной из важных целей при разработке программной системы является сокрытие от пользователей информации о модификациях реальных устройств ввода/вывода. Типичный пример такого измене- ния – это замена одного устройства другим с той же функционально- стью, но иным аппаратным интерфейсом. Разумеется, крайне нежела- тельно, чтобы подобное изменение затронуло всех пользователей. Решается проблема посредством классов интерфейса устройства, ко- торые предоставляют виртуальный интерфейс, скрывающий детали общения с реальным устройством.
С помощью класса интерфейса устройства концепция сокрытия информации применяется для инкапсуляции проектного решения о
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
206 |
том, как осуществляется интерфейс с конкретным устройством вво- да/вывода. С этой целью разрабатывается класс виртуального интер- фейса, в котором скрываются все детали реального интерфейса.
Пользователи могут обратиться к устройству только с помощью виртуального интерфейса, состоящего из набора операций. В случае замены устройства и модификации реального интерфейса пользова- тели виртуального интерфейса ничего не узнают, поскольку специ- фикация операций остается прежней. Надо лишь изменить реализа- цию этих операций. Таким образом, пользователи класса изоли- рованы от модификаций реальной аппаратуры.
Объекты интерфейса устройств определяются на этапе аналити-
ческого моделирования путем применения критериев разбиения на объекты. Такие программные объекты взаимодействуют с физиче- скими устройствами, внешними по отношению к системе. На этапе
проектирования классов разрабатываются все классы интерфейса устройств.
9.4.1.Проектирование операций классов интерфейса уст-
ройств. Экземпляры класса интерфейса устройства взаимодействуют
среальным устройством и предоставляют операции для считывания и записи.
В классе интерфейса устройства всегда есть операция инициали- зировать. Когда создается объект класса, эта операция вызывается с
целью инициализации устройства и всех внутренних переменных объекта. Что касается других операций, то они зависят от конкретно- го устройства. Например, в интерфейсе устройства ввода, скорее все- го, будет операция читать, а в интерфейсе устройства вывода – опе- рация писать. В классе же, предназначенном для работы с устройст- вом ввода/вывода, вероятно, будут обе операции.
9.4.2.Классы интерфейса устройства ввода. В классе интер-
фейса устройства ввода необходима операция инициализировать, предназначенная для инициализации устройства и установки внут- ренних переменных класса. Для устройства ввода обычно требуется операция читать. Реализация этих операций зависит от характери- стик конкретного устройства, но от пользователей устройства она должна быть скрыта.
В качестве примера рассмотрим объект Интерфейс Бензобака, у которого есть операции инициализировать и читать. Аналитическая модель (рис.9.3а) показывает, что этот объект получает запрос Чи-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
207 |
тать Количество Топлива от объекта Расход Топлива. Затем объект
Интерфейс Бензобака просит объект Бензобак сообщить, сколько бензина осталось. В проектной модели (рис.9.36) вызывается опера- ция читать внешнего объекта Бензобак, которая возвращает ответ данныеБензобака. Как это происходит на самом деле, зависит от реа- лизации физического интерфейса. Так или иначе, объект Интерфейс Бензобака возвращает вызывающему объекту количествоТоплива.
Сообщение Читать Количество Топлива, которое получает объект Интерфейс Бензобака в аналитической модели, изображено в проектной модели в виде синхронного сообщения, соответствующего вызову операции читать. Сообщение Количество Топлива, которое в аналитической модели является ответом на сообщение Читать Ко- личество Топлива, отображается на выходной параметр количество-
Топлива операции читать.
Класс Интерфейс Бензобака также изображен на диаграмме класса (рис.9.3в). У него две операции. Операция инициализировать вызывается в начальный момент. Для операции читать указан вы- ходной параметр количество Топлива. Таким образом, сигнатура опе- рации на диаграмме класса идентична тому, что мы видим на диа- грамме кооперации.
9.4.3. Классы интерфейса устройства вывода. Класс интерфей-
са устройства вывода также должен иметь операцию иници- ализировать. Кроме того, в нем должна быть операция вывода. На- пример, в классе интерфейса устройства Дроссель есть операция вы- вести. Но если устройство вывода может выполнять различные дей- ствия, то состав операций класса необходимо адаптировать. Так,
класс Устройство Выдачи Наличных имеет операцию выдатьНалич- ные, класс Устройство Печати Чеков – операцию напечататьЧек, класс Дверь Лифта – операции открыть и закрыть, а класс Мотор Лифта – операции вверх, вниз и стоп.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
208 |
Рис.9.3. Пример класса интерфейса устройства ввода:
а – аналитическая модель (диаграмма кооперации); б – проектная модель (диа- грамма кооперации); в – проектная модель (диаграмма классов)
Рассмотрим диаграмму кооперации из аналитической модели на рис.9.4а. Объект Интерфейс Маршрутного Дисплея, помеченный стереотипом «интерфейс устройства вывода», получает сообщения
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
209 |
Средняя Скорость и Средний Расход и выводит их на Маршрутный Дисплей.
Рис.9.4. Пример класса интерфейса устройства вывода:
а– аналитическая модель (диаграмма кооперации)
Вклассе Интерфейс Маршрутного Дисплея (рис.9.4в) есть две операции: вывестиСреднююСкорость (скорость) и вывестиСред-
нийРасход (расход Топлива). В данном случае объект-алгоритм Сред-
няя Скорость вызывает операцию вывестиСреднююСкорость, пере-
давая текущее значение средней скорости. На диаграмме кооперации
впроектной модели это изображено в виде синхронного сообщения без возвращаемого значения (рис.9.46). Соответственно объект-алго-
ритм Расход Топлива вызывает операцию вывестиСреднийРасход,
передавая текущее значение расхода топлива. Класс Интерфейс Маршрутного Дисплея скрывает информацию о том, как форматиру-
ются данные и как осуществляется взаимодействие с физическим
Маршрутным Дисплеем.
www.pdffactory.com