- •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. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
128 |
Рис. 7.11. Обмен данными через сеть Internet по протоколам TCP/IP
7.6. Технология World Wide Web
Огромная популярность Всемирной паутины (WWW), приду- манной Бернер-сом-Ли из Европейской организации по ядерным ис- следованиям (CERN) в Женеве привела к очень быстрому росту сети Internet. Пользователь просматривает WWW с помощью браузера типа
Netscape Communicator или Internet Explorer, работающего на машине пользователя. Страницы WWW размещены на Web-серверах. Каждая страница обычно содержит графику и ссылки на другие страницы.
Web-страница создается с помощью языка разметки, например широко распространенного языка HTML (Hyper Text Markup Language
– язык разметки гипертекста) или начавшего приобретать популяр-
ность языка XML (eXtensible Markup Language – расширяемый язык разметки). Каждая страница помечается унифицированным указате- лем ресурса (URL), который используется в составе любой ссылки на эту страницу. Когда пользователь хочет просмотреть страницу, брау- зер берет из URL адрес сервера и обращается к нему с просьбой за- грузить необходимые данные (рис. 7.12). Затем браузер отображает полученную страницу на экране. Web-браузер и Web-сервер общают-
ся друг с другом по протоколу HTTP (HyperText Transfer Protocol –
протокол передачи гипертекстовых файлов). Web-сервер принимает запросы на страницы одновременно от многих клиентов.
Внешний модуль, или вставка (plug-in), – это программа, кото-
рая помещается в браузер и расширяет его возможности – скажем,
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
129 |
позволяет обрабатывать аудио- и видеоданные, посылаемые серве- ром. Внешний модуль может входить в дистрибутив браузера или за- гружаться отдельно с определенного сервера.
Рис. 7.12. Web-браузер и Web-сервер в приложении WWW
7.6.1. Язык Java и World Wide Web
С появлением WWW и Web-браузеров в начале 90-х годов брау- зер стал распространенным пользовательским интерфейсом для рас- пределенных приложений. Рост популярности Всемирной паутины вывел на авансцену язык программирования Java, который широко применяется для создания апплетов.
Java-апплет – это программа на языке Java, которая загружается клиентом с сервера в виде так называемого байт-кода. Апплет рабо- тает совместно с браузером, который интерпретирует полученный код. Чтобы Web-браузер мог успешно принимать апплеты, он должен поддерживать язык Java. Интерпретатор на стороне клиента обраба- тывает промежуточный байт-код и генерирует объектный код, испол- няемый клиентом. Итак, Java-апплет – это объект, который загружа- ется с Web-сервера и исполняется клиентом (рис. 7.13). Java-апплет часто используются для анимации Web-страниц. Клиентский Java- объект может также взаимодействовать с серверным объектом, рас- положенным на том же сервере, с которого был загружен апплет. Коммуникации между распределенными Java-объектами обычно осуществляются с помощью технологии RMI (Remote Method Invocation – вызов удаленных методов).
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
130 |
Рис. 7.13. Java-апплет, загружаемый с Web-сервера в приложении WWW
Java-программы способны работать и на Web-сервере, тогда они называются сервлетами. Сервлеты, как и апплеты, часто тесно интег- рированы с Web-сервером, чтобы удовлетворить требованиям безо- пасности и производительности. В наши дни, когда к сети Internet стали подключать такие нетрадиционные устройства, как телефоны и банкоматы, появилась острая нужда в сверхтонких клиентах. Такой клиент состоит из одного браузера. Объекты уровня представления пользовательского интерфейса остаются на сервере вместе с бизнес- объектами, реализованными в виде сервлетов.
7.7. Сервисы распределенных операционных систем
Распределенная система состоит из компьютеров, соединенных коммуникационной средой, например локальной сетью. Рассмотрим некоторые базовые сервисы, предоставляемые распределенной опе- рационной системой, дополнительные по отношению к описанным ранее.
7.7.1. Служба имен. В распределенной среде желательно обес- печить независимость сервисов от местоположения. Это значит, что компонент, желающий послать сообщение другому компоненту, не обязан знать, где находится адресат. Если требовать, чтобы компо- нент А явно указывал местоположение компонента В, система полу- чится негибкой: при перемещении компонента В придется обновлять компонент А. Поэтому необходима глобальная служба именования, обеспечивающая отделение имен от местоположения сервисов.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
131 |
При наличии службы именования сервер имен хранит имена глобальных сервисов. Предполагается, что местоположение самого сервера имен хорошо известно. Каждый сервер регистрирует имена и местоположения предоставляемых им сервисов у сервера имен. Если клиент хочет получить доступ к некоторому сервису, он запрашивает информацию о нем у сервера имен.
Пример службы имен – это система доменных имен (DNS), ис- пользуемая в сети Internet. Узлам здесь присваиваются уникальные 32-битовые идентификаторы, называемые IP-адресами. IP-адрес за- писывается в десятичной нотации, в которой каждые восемь бит ко- дируются десятичным числом, а сами числа разделяются точками, например 128.174.40.15. Узлу назначается также уникальное симво- лическое имя, например ise.gnu.edu. Серверы Internet-имен хранят таблицы, с помощью которых символические имена (называемые также доменными именами) отображаются на IP-адреса. Поскольку число пользователей Internet очень велико, служба имен распределе- на между многими серверами.
7.7.2.Связывание клиентов и серверов. Термин связывание от-
носится к ассоциации между клиентом и сервером. Статическое свя- зывание выполняется на этапе компиляции и означает, что все обра- щения клиента к серверу жестко «зашиты» в код.
Динамическое связывание производится во время выполнения. Оно характеризуется большей гибкостью, чем статическое, но мень- шей эффективностью. Для динамического связывания необходимо указать имя сервера, который ведет справочник имен и адресов сер- веров. Каждый сервер регистрирует свое местоположение и предос- тавляемые сервисы у сервера имен. Клиент посылает запрос серверу имен, передавая имя серверного объекта, и получает ссылку на него. Затем эта ссылка используется для доступа к удаленному серверу.
7.7.3.Сервисы распределенного обмена сообщениями. Прозрач-
ный обмен сообщениями между распределенными задачами можно реализовать с помощью распределенного ядра распределенной опе- рационной системы. На рис.7.14 приведен пример межзадачной ком- муникации с использованием такого ядра. В каждом узле существует один экземпляр распределенного ядра. Сервер имен хранит главную копию таблицы имен. В тех распределенных приложениях, где число задач относительно постоянно, каждое распределенное ядро также может содержать собственную копию этой таблицы. На стадии на-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
132 |
чальной загрузки системы распределенное ядро посылает запрос сер- веру имен с просьбой загрузить таблицу имен.
Когда задача-отправитель посылает сообщение задаче- получателю, локальное ядро определяет местоположение адресата по своей таблице имен. Если получатель находится в том же узле, что и отправитель, то локальное ядро направляет сообщение непосредст- венно по назначению. Так, на рис.7.14 сообщение от задачи В достав- ляется напрямую задаче С, так как обе они работают в узле 1. Если же задача-получатель находится в другом узле, то локальное ядро посы- лает сообщение удаленному ядру, расположенному на нужном узле. Получив сообщение, удаленное ядро переправляет его задаче- получателю. Такая ситуация проиллюстрирована на примере задачи А в узле 1, которая посылает сообщение задаче D в узле 2.
Рис. 7.14. Прозрачный поиск сервисов в распределенных приложениях
7.7.4.Сервисы сокетов. Сокеты – это интерфейс прикладных программ (API), предоставляемый многими операционными система- ми. Он определяет набор операций, доступных приложению для ор- ганизации обмена данными по сети с другим приложением (на- пример, между клиентом и сервером) по заданному протоколу, на- пример TCP/IP. Сокеты – низкоуровневый механизм коммуникаций, поэтому впоследствии были разработаны более абстрактные интер- фейсы, снимающие с приложения заботу о низкоуровневых деталях.
Ких числу относятся RPC (Remote Procedure Call – вызов удаленных процедур) и различные технологии ПО промежуточного слоя.
7.7.5.Обмен сообщениями через порты. В некоторых распреде-
ленных системах обмен сообщениями между удаленными узлами реализован с помощью портов, что позволяет максимально ослабить
www.pdffactory.com