- •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. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
107 |
В нотации UML активный объект или задача изображается пря- моугольником с жирной границей. Активный объект имеет собствен- ный поток управления и исполняется параллельно с другими объек- тами. Этим он отличается от пассивного объекта, не имеющего сво- его потока управления.
Пассивный объект исполняется только тогда, когда другой объ- ект (активный или пассивный) вызовет одну из его операций. Будем называть активный объект задачей, а пассивный – просто объектом.
Задачи отмечаются на диаграммах параллельной кооперации, которые позволяют наглядно представить параллелизм в системе [17]. На та-
кой диаграмме задача показывается в виде прямоугольника с жирной границей, а пассивный объект – в виде прямоугольника с тонкой гра- ницей (рис. 6.10, здесь представлена также нотация для множества объектов, возникающих при порождении нескольких объектов одного класса).
Рис. 6.10. Нотация UML для активных и пассивных объектов
6.8.1. Обмен сообщениями на диаграммах параллельной коопе-
рации. Интерфейс для обмена сообщениями на диаграмме параллель- ной кооперации может быть слабо связанным (loosely coupled) или сильно связанным (tightly coupled). В последнем случае производитель посылает сообщение потребителю и ожидает немедленного подтвер- ждения. Сильно связанный обмен бывает двух видов: сильно связан-
ный обмен сообщениями с ответом и сильно связанный обмен сооб- щениями без ответа.
Нотация UML для нескольких видов обмена сообщениями пред- ставлена на рис. 6.11. На рис.6.12 изображен вариант диаграммы коо- перации с активными объектами (параллельными задачами или про- цессами), а также разные типы передачи информации между ними.
6.9. Диаграммы развертывания
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
108 |
На диаграмме развертывания очерчивается физическая конфи- гурация системы, то есть физические узлы и соединения между ними (например, связывающая их сеть). Узел представляется в виде куба, а соединение – в виде линии, ведущей от одного куба к другому. По сути, диаграмма развертывания – не что иное, как диаграмма классов с акцентом на узлах системы [16].
Узлом, как правило, является компьютер, при этом макси- мальное число экземпляров узла может быть ограничено (см. раздел 6.10). Для физического соединения имеется стереотип, задающий тип соединения, например «локальная сеть» или «глобальная сеть». На рис. 6.13 показаны узлы двух типов: банкомат (каждый такой клиент занимает ровно один узел), соединенный с банковским сервером, ко- торый также размещен в одном узле. В кубе, представляющем узел, могут также изображаться объекты, находящиеся в этом узле. Во вто- ром примере, где несколько клиентов и серверов соединены локаль- ной сетью, сама сеть также присутствует в виде узла. Подобная нота- ция применяется в тех случаях, когда в сети есть более двух узлов- компьютеров.
Рис. 6.11. Нотация UML для сообщений
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
109 |
Рис. 6.12. Нотация UMLдля. параллельной диаграммы кооперации
Рис. 6.13. Нотация UML для диаграммы развертывания
6.10.Механизмы расширения UML
ВUML имеется три механизма расширения языка [16]:
– стереотипы. Стереотип определяет новый строительный блок, производный от существующего в UML элемента моделирова-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
110 |
ния, но адаптированный к решаемой задаче. В UML определено не- сколько стандартных стереотипов, но проектировщик может созда- вать и собственные. Названия стереотипов заключаются в кавычки. На рис.6.1 два вида зависимостей между прецедентами отмечены сте- реотипами «include» и «extend». На рис.6.9 представлены стереотипы «система» и «подсистема» для обозначения разных видов пакетов. На рис.6.10 стереотипы помогают отличить активные объекты от пас- сивных: активному объекту соответствует стереотип «задача», а пас- сивному – «объект». На рис.6.11 с помощью стереотипов задаются разные виды сообщений;
– помеченные значения. Помеченное значение расширяет свой- ства строительного блока UML, сообщая тем самым новую информа- цию. Оно заключается в фигурные скобки {метка = значение}. Друг от друга помеченные значения отделяются запятыми. Например, класс на рис. 6.14 имеет два помеченных значения (номер версии и автор): {версия = 1.0, автор = Gill};
Рис. 6.14. Нотация UML
для помеченных значений и ограничений
– ограничения. Ограничение задает условие, которое должно выполняться. В UML ограничение семантически расширяет элемент, добавляя новые правила или изменяя существующие. Напри-мер, в классе Счет на рис.6.14 есть ограничение на атрибут баланс, со- стоящее в том, что баланс не должен быть отрицательным {баланс ≥ 0}. Помимо этого, в состав UML входит объектный язык ограничений
Object Constraint Language [28].
www.pdffactory.com