- •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. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
142 |
гии входят также протоколы для обнаружения, присоединения и по- иска ресурсов. Сервис-провайдер, например цифровой видеомагни- тофон, регистрируется в службе имен Jini. Поэтому новый провайдер должен сначала динамически найти службу поиска (эта процедура называется обнаружением), а затем зарегистрироваться в ней (проце- дура присоединения). Для каждого сервиса, который собирается пре- доставлять провайдер, он должен загрузить Java-объект, обеспечи- вающий интерфейс к данному сервису.
Клиент Jini, скажем цифровая видеокамера, отыскивает службу имен, пользуясь протоколом обнаружения. Затем с помощью этой службы клиент находит нужный сервис – допустим, сервис записи, предоставляемый видеомагнитофоном, – после чего загружает из службы поиска Java-объект, который позволит ему напрямую взаи- модействовать с устройством. Таким образом, видеокамера пользу- ется службой имен для поиска сервиса видеомагнитофона, загружает объект записи на магнитофон, а затем работает уже непосредственно с магнитофоном.
7.11. Системы обработки транзакций
Приложения для обработки транзакций (или просто транзакци- онные приложения) относятся к классу критических для бизнеса или иной деятельности [14]. Сюда входят системы ввода заказов, резер- вирования авиабилетов и кассовые терминалы. Транзакционное при- ложение занимается обновлением информации в базе данных. На- грузка на такое приложение обычно предсказуема, значительную до- лю в ней занимают запросы на обновление. Известны также требова- ния в периоды пиковой нагрузки, поэтому можно оценить структуру множества запросов к базе. Некоторые транзакционные приложения должны работать постоянно, в других допустимы короткие пе- рерывы.
7.11.1. Характеристики транзакций. Транзакция – это запрос клиента к серверу, состоящий из двух или более операций, которые образуют единую логическую функцию, причем она должна быть ли- бо выполнена полностью, либо не выполнена вовсе. Транзакции по- рождаются клиентом и посылаются серверу для обработки. В класси- ческой конфигурации клиента и сервера обработка целиком возлага- ется на сервер. В распределенных приложениях сервер может делеги- ровать одну или несколько операций другим серверам.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
143 |
Рассмотрим, к примеру, электронный перевод денежных средств. Чтобы транзакция считалась завершенной, требуется успеш- но провести все операции. Если какую-то операцию осуществить не удается, транзакцию следует отменить. Это означает, что результаты выполнения отдельных составляющих операций необходимо аннули- ровать, чтобы система пришла в такое состояние, как будто данная транзакция и не начиналась.
У транзакций выделяются следующие свойства:
§атомарность. Транзакция – это неделимая единица работы. Она либо выполняется полностью (фиксируется), либо не вы- полняется вовсе (откатывается);
§непротиворечивость. После завершения транзакции система должна оказаться в непротиворечивом состоянии;
§изолированность. На поведение транзакции не должны ока- зывать влияния другие транзакции;
§долговечность, или устойчивость. Изменения сохраняются после завершения транзакции, даже если за ним последует сбой системы.
7.11.2. Мониторы обработки транзакций. Монитор обработки транзакций (ТР-монитор) координирует поток информации между различными клиентами, инициирующими запросы, и приложением обработки транзакций, которое отвечает на эти запросы. ТР- мониторы уже много лет существуют на больших ЭВМ. Наиболее широко известна программа CICS компании IBM, функционирующая
соперационными системами и СУБД, которые поставляет IBM.
Вгетерогенной клиент-серверной среде ТР-мониторы выполня- ют следующие действия:
§посылают и принимают сообщения от клиентов и серверов;
§управляют потоком транзакций и распределяют нагрузку ме- жду серверами;
§поддерживают глобальные транзакции, которые относятся к нескольким распределенным базам данных, в частности га- рантируют резервное копирование и восстановление глобаль- ных транзакций;
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
144 |
§реализуют интерфейс с менеджерами ресурсов, например с ОС и СУБД;
§редоставляют средства для администрирования системы.
§Современные ТР-мониторы, такие как Tuxedo или Enema, поддерживают трехуровневую архитектуру клиент-сервер:
§функциональность клиента. Представление информации и взаимодействие с пользователем. Например, клиент может находиться на персональном компьютере;
§функциональность сервера приложений, поддерживающего бизнес-логику. Клиент общается с сервером приложений по- средством сообщений;
§управление данными. В частности, реляционная база данных под управлением СУБД Oracle может быть распределена ме- жду несколькими узлами.
Изоляция клиента от сервера приложений позволяет раздельно проектировать и разрабатывать пользовательский интерфейс и биз- нес-логику.
www.pdffactory.com