Предыдущая страница реферата | 13  14  15  16  17  18  19  20  21  22  23 | Следующая страница реферата

В методе EDF приоритеты задачам назначаются исходя из их крайних сроков на текущий момент. В этом случае задача с ближайший крайним сроком получает наивысший приоритет. Этот метод также является оптимальным в том смысле, что если можно найти исполнимое расписание для данного множества задач с фиксированными приоритетами, то всегда можно найти исполнимое расписание и с использованием этого метода. Однако он является оптимальным только при недогрузке системы, но в условиях перегрузки ведёт себя довольно плохо.

Данный метод часто считается опасным из-за того, что при условии перегрузки системы он может показать нежелательное поведение. Однако во время работы жёстких систем реального времени перегрузок не должно возникать, потому что невыполнение крайнего срока задачи может привести к серьёзным последствиям. Поэтому для таких систем необходимо проводить априорное доказательство того, что когда у всех задач в системе одновременно возникнут потребности в системных ресурсах, то все их ограничения по времени по-прежнему будут выполнены.

5. Сервер, допускающий задержку (DS) и Алгоритм обмена приоритетами (PE).

Эти методы сохраняют доступными ресурсы системы, первоначально выделенные для апериодических задач.

Эти методы улучшают среднее время ответа системы и отличаются друг от друга способом сохранения пропускной способности. PE алгоритм раздаёт время выполнения, выделенное для работы высокоприоритетного периодического сервера, другим периодических задачам с меньшим приоритетом, если оно не нужно для работы апериодических задач.

В отличие от него DS не отдаёт время выполнения этой задачи, когда не осталось ни одной апериодической задачи. Вместо этого он хранит это высокоприоритетное время выполнения либо пока не прибудет апериодическая задача, либо пока не закончится период сервера.

Этот метод проще в реализации, но хуже в исполнении.

4. Методология разработки программного обеспечения.

1. Основы методологии Real.

Не останавливаясь, в общем, на процессе разработки программного обеспечения, перечислим, какие модели используются в Real для описания разрабатываемой системы:

. Модель требований к системе:

Описательная модель — в текстовом виде описывает некоторые требования к системе.

Модель случаев использования — описывает требования, предъявляемые к системе ее окружением, т.е. отвечает на вопрос “что и для кого должна делать система?”.

Функциональная модель — описывает разбиение случаев использования и функций на подфункции. Дает ответ на вопрос “как должны реализовываться функции системы в терминах своих подфункций?”.

. Динамическая модель:

Модель объектов — описывает роли объектов системы и отвечает на вопрос
“какие объекты взаимодействуют при выполнении функций системы?”.

Модель взаимодействий — описывает сценарии взаимодействия объектов системы между собой и с пользователями, т.е. дает ответ на вопрос “как объекты взаимодействуют друг с другом для выполнения функций системы?”.

Поведенческая модель — описывает алгоритмы поведения объектов системы, т.е. отвечает на вопрос “как должен вести себя каждый объект для реализации функций системы?”.

. Статическая модель:

Модель классов — описывает внутреннюю структуру системы, структуры данных, используемые в ней, т.е. отвечает на вопрос “как должна выглядеть система изнутри?”.

В Real большой упор был сделан на связность моделей, на контроль целостности информации о проекте, представленной внутри как одной модели, так и в нескольких.

2. Модель требований.

Работа над системой в Real начинается с построения описательной модели, в которую, прежде всего, входят первичные требования заказчика.
Среди них могут быть как функциональные требования, так и любые другие
(эффективность, стоимость и т.п.). Описательная модель хранится в Real в виде обычного текста и формально не связана с остальными моделями. Эта модель может быть использована и для окончательной спецификации нефункциональных требований.

На основе требований заказчика формулируется полный список функциональных требований к системе, которые оформляются в терминах модели случаев использования и модели функций. Окончательное техническое задание на систему может быть сгенерировано по модели требований Real в том виде, который нужен заказчику (ГОСТ, какой-либо международный или внутрикорпоративный стандарт и т.п.).

Модель случаев использования в Real предназначена для описания стыка системы с окружением. В ее терминах описываются все пользователи системы, а также все ее функции (случаи использования), различимые с точки зрения этих пользователей. В дальнейшем с использованием могут быть связаны классы. Для случаев использования, в свою очередь, можно создавать диаграммы этого же типа, т.е. подвергать случаи использования дальнейшей декомпозиции в рамках той же модели.

Рекомендуем скачать другие рефераты по теме: реферат ссср, скачать шпоры.





Предыдущая страница реферата | 13  14  15  16  17  18  19  20  21  22  23 | Следующая страница реферата