Ограниченное время ответа
Особенности управления задачами
Ядра реального времени
Время переключения контекста
OS-9/Hawk фирмы Microware Systems
Методология разработки программного обеспечения
Вывод
Принципиальная структура
Обработка запросов внешних устройств
Планирование апериодических задач
Последний шанс
Динамическая модель
Абсолютные ограничения
Работа
Модель взаимодействий
Навигация
Динамическая модель
Разработка системы реального времени в виде планировщика исполнения заданий
104513
знаков
2
таблицы
0
изображений
2.4.3. Динамическая модель.
Она описывает поведение системы — взаимодействие между различными ее компонентами, взаимодействие системы с ее окружением и поведение самих компонент.
На начальных этапах разработки можно придерживаться одной из двух стратегий. Первая: сначала специфицировать классы системы, а затем объекты и сценарии взаимодействия. Она будет использоваться с большей вероятностью, если разработчикам хорошо знакома предметная область. Возможна и другая стратегия — в том случае, если на этапе анализа приходится изучать незнакомую предметную область. Основное назначение модели объектов — описание различных ролей, которые могут играть экземпляры классов системы. Каждой функции из функциональной модели Real можно сопоставить диаграмму объектов, назначение которой — описать типичную ”конфигурацию” объектов, задействованных в осуществлении данной функции, а также описать связи между ними. При использовании объектно-ориентированного подхода выполнение функций системы реализуется как совместная деятельность нескольких объектов. Основными ее элементами являются объекты-роли и отношения между ними.
Динамику взаимодействия объектов для реализации функции (модель взаимодействия) удобно представлять в виде сценариев. В этих сценариях принимают участие объекты-роли, определенные на диаграмме объектов для данной функции или ее надфункций. Сценарий представляет собой упорядоченную во времени последовательность событий, которыми, как правило, являются посылки и приемы сообщений объектами.
Построение сценариев для функции начинается с определения ”прямых веток”, т.е. идеального исполнения функции. При этом из рассмотрения исключаются граничные, ошибочные ситуации, частные случаи и т.п., для них впоследствии тоже строятся сценарии либо они специфицируются другими средствами.
Поведенческая модель описывает поведение составляющих систему классов с помощью расширенного конечного автомата и представлена в Real двумя нотациями: в стиле STD и SDL. Фактически, поведенческая модель определяет процессы, протекающие в системе в терминах состояний, событий и действий. В дальнейшем будем говорить о поведенческой модели отдельного класса. Построение такой модели можно начать с анализа всех сценариев, в которых участвуют объекты-роли данного класса. Проектирование поведения системы (поведения ее классов) на основе сценариев, а не напрямую, позволяет в более наглядном виде представлять общие процессы, протекающие в программном обеспечении, и, отталкиваясь от них, конструировать внутреннее поведение участников этих процессов.
2.4.4. Статическая модель.
После того, как созданы основные сценарии системы, можно переходить к спецификации их участников — объектов, т.е. к построению модели классов. Эта модель классов строится на протяжении всего процесса разработки программного обеспечения.
В Real в модели классов могут быть следующие виды сущностей:
• класс — описание группы однородных объектов;
• шаблон — параметризованный класс с возможностью получения из него обычного класса подстановкой значений параметров;
• интерфейс — описание правил взаимодействия классов;
• представление — аналог конструкции VIEW языка SQL.
Модель классов Real реализует достаточно полное подмножество модели классов UML. Кроме того, в ней есть интерфейсы и порты из ROOM, при этом последние существенно расширены. Модель классов Real содержит также средства моделирования схемы баз данных.
3. Реализация прототипа системы реального времени.
3.1. Жизненный цикл разработки.
Разработка состоит из двух основных частей: планировщика задач РВ и прикладного приложения. Прямых зависимостей между этапами проектирования данных систем нет. Однако, существуют логические связи. Приложение строится на основе созданного планировщика, что предполагает знание о предоставляемых им интерфейсах. Планировщик, в свою очередь, строится с учетом особенностей приложения, которое является приложением контроля, т.е. ориентированным на обработку внешних стохастических событий.
На диаграмме 1 представлены этапы разработки программной системы. Выполненные в рамках данной работы, выделены чёрным цветом, предполагаемые к исполнению в дальнейшем – серым.
Для планировщика выбрана V – образная модель жизненного цикла. Она применяется для приложений, при проектировании которых разработчикам приходится исследовать новую проблемную область. Отличительной особенностью этой модели жизненного цикла является наличие обратных связей уже на этапах тестирования и верификации. Предполагается, что это позволит создать более гибкую в плане предоставляемых возможностей систему.
Для приложения-протокола выбрана каскадная модель жизненного цикла. Она применяется для приложений в хорошо исследованных областях знаний. В данном случае системные требования на протокол уже описаны в технической документации.
В данной работе будут выполнены этапы создания системных и функциональных требований к планировщику, а также определение его архитектуры. Для протокола будет выполнена функциональная модель и модель классов.
3.2. Планировщик заданий.
3.2.1. Выбор алгоритма планирования.
3.2.1.1. Виды требований РВ, поддерживаемые планировщиком.
Во многих системах можно заранее установить множество задач, которые будут использоваться, и предположить их характеристики работы в худшем случае. При этом можно либо провести фиксированное планирование, которое будет удовлетворять требованиям системы, либо определить предварительные приоритеты задач.
Следующие ограничения будет возможно задавать с помощью создаваемого планировщика. Они основаны на временном поведении задач.
Похожие работы
... элементов, глобальное пространство имен, а также лавинообразную первоначальную загрузку сети. Таким образом ОСРВ SPOX имеет необходимые механизмы для создания отказоустойчивой распределенной операционной системы реального времени, концепция построения которой описана в главе 2. 4.3 Аппаратно-зависимые компоненты ОСРВ Модули маршрутизации, реконфигурации, голосования реализованы как аппаратно- ...
... запрошенный ею ресурс, произошло связанное с ней внешнее событие, исчерпался заданный интервал времени и т. п. Заканчивая рассмотрение основных принципов планирования задач, необходимо отметить, что тема эта далеко не исчерпана. Диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где ...
... же порты ввода-вывода или линии запроса прерывания. С такими проблемами, как конфликты различных частей аппаратуры, приходится иметь дело в основном именно операционным системам. Наконец, в-восьмых, при разработке операционных систем часто учитывается необходимость совместимости с предыдущей версией операционной системы. Система может иметь множество ограничений на длину слов, имена файлов и т. ...
... заявить, что все его ресурсы доступны для всех пользователей группы. Такая схема может быть многоуровневой (группы делятся на подгруппы и т.д.) с соответственным распределением прав и возможностей. Сейчас появляются операционные системы, в которых права доступа могут определяться не только такой иерархической структурой, но и могут быть более сложными, т. е. права доступа можно добавлять, нарушая ...
0 комментариев