- •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. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
99 |
6.Обзор нотации UML
Вметоде COMET используется нотация из унифицированного языка моделирования UML, которая объединила нотации, предло- женные Бучем [16], Джекобсоном [21], Рамбо [16] и Харелом [20]. Представим краткий обзор нотации UML.
Co временем нотация UML расширялась, и теперь в ней поддер- живается много различных диаграмм.
6.1.Диаграммы UML
Внотации UML поддерживаются девять видов диаграмм:
§диаграммы прецедентов;
§диаграммы классов;
§диаграммы объектов, являющиеся вариантом диаграмм клас- сов в применении к экземплярам. В методе COMET вместо них работают консолидированные диаграммы кооперации;
§диаграммы кооперации;
§диаграммы последовательности;
§диаграммы состояний;
§диаграммы деятельности (в COMET не используются);
§диаграммы компонентов (в COMET не используются).
§диаграммы развертывания.
6.2.Диаграммы прецедентов
Актер (actor) инициирует прецедент. Прецедент (use case) опи- сывает последовательность взаимодействий между актером и систе- мой. Актер изображается на диаграмме прецедентов в виде фигуры человечка, система – в виде прямоугольника, прецедент – в виде эл- липса внутри этого прямоугольника. Коммуникационные ассоциации связывают актеров с теми прецедентами, в которых они участвуют. Между прецедентами могут быть отношения include (включает) и extend (расширяет). Пример диаграммы прецедентов представлен на рис.6.1.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
100 |
6.3. Нотация UML для классов и объектов
Классы и объекты изображаются в UML прямоугольниками, как показано на рис.6.2.
Рис. 6.1. Диаграммы прецедентов в нотации UML
В прямоугольнике класса всегда вписано имя класса. Дополни- тельно могут быть указаны атрибуты и операции класса. Когда при- сутствуют все три элемента, то в верхней секции прямоугольника на- ходится имя класса, в средней – атрибуты, а в нижней – операции.
Для того чтобы отличить класс (тип) от объекта (экземпляра типа), имя объекта подчеркивается. Объект может обозначаться как anObject,anotherObject:Class или :Class. Классы и объекты встреча-
ются в разных диаграммах UML.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
101 |
Рис. 6.2. Объекты и классы в нотации UML
6.4. Диаграммы классов
На такой диаграмме классы изображаются в виде прямоуголь- ников, а статические (постоянные) отношения между ними – в форме дуг. Поддерживаются три основных типа отношений между классами
(рис. 6.3):
–ассоциации. Ассоциация между двумя классами (бинарная ас- социация) изображается в виде линии, соединяющей прямоугольники классов. У нее есть имя и, возможно, стрелка, поясняющая, в каком направлении следует это имя читать. На каждом конце ассоциации проставляется кратность – число, свидетельствующее, сколько экзем- пляров одного класса связано с одним экземпляром другого класса.
Дополнительно на каждом конце ассоциации может присутствовать стрелка, указывающая направление навигации вдоль данной ассоциа- ции.
Допустимы следующие кратности ассоциации: ровно один (1), присутствие экземпляра класса необязательно (0..1), нуль или более (*), один или более (1..*) и точное задание числа экземпляров классов
(m..n), где m и n - числа;
–иерархии агрегирования и композиции. Это отношения вида целое/часть. Отношение композиции (изображается закрашенным ромбом) накладывает более сильные ограничения на экземпляры классов, чем отношение агрегирования (показывается незакрашен- ным ромбом). Ромб одной вершиной примыкает к прямоугольнику класса, являющегося частью в отношении вида «часть/целое»;
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
102 |
– иерархия обобщения/специализации. Это отношение вида «яв-
ляется». Обобщение изображается в виде стрелки, ведущей от под- класса (потомка) к суперклассу (родителю), причем стрелка упирает- ся в прямоугольник суперкласса.
Видимость определяет, доступен ли элемент класса вне самого класса (рис. 6.4). Показывать видимость на диаграмме необязательно. Открытая видимость, изображаемая символом + (плюс), означает, что элемент виден извне класса.
Закрытая видимость, отмеченная знаком – (минус), свидетельст- вует о том, что элемент виден только внутри класса, в котором он оп- ределен, а от других классов скрыт. Защищенная видимость, показы- ваемая знаком #, говорит о том, что элемент виден внутри класса, в котором определен, а также во всех подклассах этого класса.
Рис. 6.3. Нотация UML для связей на диаграмме классов
Рис. 6.4. Нотация UML для обозначения видимости на
диаграмме классов
www.pdffactory.com