Шпоры - Системы реального времени (по Сулеймановой)

Подождите немного. Документ загружается.

1. Что такое функционирование в

«Реальном масштабе времени»

Каноническое определение системы

реального времени дано Дональдом

Гиллиесом и выглядит так: «Системой

реального времени является такая система,

корректность функционирования которой

определяется не только корректностью

выполнения вычислений, но и временем, в

которое получен требуемый результат. Если

требования по времени не выполняются, то

считается, что произошел отказ системы».

Другие добавляют: «Поэтому необходимо,

чтобы было гарантировано выполнение

требований по времени. Гарантия

выполнения требований по времени

необходима, чтобы поведение системы было

предсказуемо. Также желательно, чтобы

система обеспечивала высокую степень

использования ресурсов, чтобы

удовлетворять требованиям по времени».

ОС РВ характеризуется прежде всего

малым временем реакции на внешние

события. Последние версии ОС имеют

прерываемое микроядро, что гарантирует

быструю реакцию на внешнее событие при

любом состоянии системы. Особенность

большинства ОС – возможность

стопроцентного размещения в памяти ядра,

сетевого и графического обеспечения,

драйверов и прикладных программ. Для

встроенных бездисковых систем это

чрезвычайно важно.

Традиционно ОС РВ делятся на

"жесткие" и "мягкие". Система "жесткого" РВ

должна без сбоев отвечать на внешние

события в рамках заранее определенного

интервала времени. Время ответа должно

быть предсказуемым и не зависеть от

текущего состояния системы. "Мягкая" ОС РВ

тоже должна отвечать очень быстро, но

гарантированное время ответа в ней не

обеспечивается. Здесь нужно отметить, что

временные характеристики последних версий

промышленных ОС практически стерли ранее

существовавшую грань между двумя этими

разновидностями. Сейчас OS-9, ранее

считавшаяся "мягкой" ОС, практически не

уступает классическим "жестким" ОС - pSOS+

и VxWorks.

2. Ядра и операционные системы

реального времени

Примем как очевидные следующие

моменты.

1. Когда-то операционных систем совсем

не было.

2. Через некоторое время после их появ-

ления возникло направление ОС РВ.

3. Все ОС РВ являются многозадачными

операционными системами. Задачи делят

между собой ресурсы вычислительной

системы, в том числе и процессорное время.

Четкой границы между ядром (Kernel) и

операционной системой нет. Различают их,

как правило, по набору функциональных

возможностей. Ядра предоставляют

пользователю такие базовые функции, как

планирование и синхронизация задач,

межзадачная коммуникация, управление

памятью и т.п. Операционные системы в

дополнение к этому имеют файловую

систему, сетевую поддержку, интерфейс с

оператором и другие средства высокого

уровня.

По своей внутренней архитектуре ОС РВ

можно условно разделить на монолитные ОС,

ОС на основе микроядра и объектно-

ориентированные ОС.

3. Задачи, процессы, потоки

Принято различать две разновидности

задач: процессы и потоки. Процесс

представляет собой отдельно загружаемый

программный модуль (файл), который, как

правило, во время исполнения имеет в

памяти свои независимые области для кода и

данных. В отличие от этого потоки могут

пользоваться общими участками кода и

данных в рамках единого программного

модуля.

Преимущества потоков.

1. Так как множество потоков способно

размещаться внутри одного EXE-модуля, это

позволяет экономить ресурсы как внешней,

так и внутренней памяти.

2. Использование потоками общей об-

ласти памяти позволяет эффективно

организовать межзадачный обмен

сообщениями (достаточно передать

указатель на сообщение). Процессы не имеют

общей области памяти.

3. Как правило, контекст потоков

меньше, чем контекст процессов, а значит,

время переключения между задачами-

потоками меньше, чем между задачами-

процессами.

4. Так как все потоки, а иногда и само

ядро РВ размещаются в одном ЕХЕ-модуле,

значительно упрощается использование

программ-отладчиков

Недостатки потоков.

1. Как правило, потоки не могут быть

подгружены динамически. Процессы, в

отличие от потоков, подгружаемы, что

позволяет динамически изменять функции

системы в процессе ее работы.

2. То, что потоки имеют доступ к

областям данных друг друга, может привести

к ситуации, когда некорректно работающий

поток способен испортить данные другого

потока. В отличие от этого процессы

защищены от взаимного влияния, а попытка

записи в «не свою» память приводит, как

правило, к возникновению специального

прерывания по обработке «исключительных

ситуаций».

Реализация механизмов управления

процессами и потоками, возможность их

взаимного сосуществования и взаи-

модействия определяются конкретным ПО

РВ.

4. Основные свойства задач

Приоритет – это некое целое число,

присваиваемое задаче и характеризующее ее

важность по сравнению с другими задачами,

выполняемыми в системе. Приоритет

используется в основном планировщиком

задач для определения того, какая из готовых

к работе задач должна получить управление.

Различают системы с динамической и ста-

тической приоритетностью.

Контекст задачи – это набор данных,

содержащий всю необходимую информацию

для возобновления выполнения задачи с того

места, где она была ранее прервана. Плани-

ровщик задач в случае необходимости

сохраняет контекст текущей активной задачи

и восстанавливает контекст задачи,

назначенной к исполнению. Такое

переключение контекстов и является, по сути,

основным механизмом ОС РВ при переходе

от выполнения одной задачи к выполнению

другой.

Состояние (статус) задачи. С точки

зрения операционной системы, задача может

находиться в нескольких состояниях. Тем не

менее, практически в любой ОС РВ

загруженная на выполнение задача может

находиться, по крайней мере, в трех

состояниях.

1. Активная задача – это задача, выпол-

няемая системой в текущий момент времени.

2. Готовая задача – это задача, готовая к

выполнению и ожидающая у планировщика

своей «очереди».

3. Блокированная задача – это задача,

выполнение которой приостановлено до

наступления определенных событий.

Пустая задача – это задача, запускаемая

самой операционной системой в момент

инициализации и выполняемая только тогда,

когда в системе нег других готовых для

выполнения задач. Пустая задача

запускается с самым низким приоритетом и,

как правило, представляет собой

бесконечный цикл «ничего не делать».

Многократный запуск задач. Как

правило, многозадачные ОС позволяют

запускать несколько копий одной и той же

задачи. В целях экономии памяти может быть

предусмотрено совместное использование

одного и того же исполняемого кода для всех

запущенных копий. В этом случае программа

должна обеспечивать повторную входимость

(реентерабельность).

Реентерабельность (повторная

входимость) означает возможность без

негативных последствий временно прервать

выполнение какой-либо функции или

подпрограммы, а затем вызвать эту функцию

или подпрограмму снова.

5. Планирование задач

Важной частью любой ОС РВ является

планировщик задач. Его функции остаются

теми же: определить, какая из задач должна

выполняться в системе в каждый конкретный

момент времени. Самым простым методом

планирования, не требующим никакого специ-

ального ПО и планировщика как такового,

является использование циклического

алгоритма стиле round robin:

Каждая «задача», представляющая со-

бой отдельную подпрограмму, выполняется

циклически. При этом надо придерживаться

следующих правил:

1. Подпрограммы не должны содержать

циклов ожидания

2. Подпрограммы должны выполнять

свою работу как можно быстрее

3. При необходимости подпрограмма

может сохранять свое окружение и текущие

результаты, чтобы в следующем цикле

возобновить работу с того же места.

Можно отметить следующие преиму-

щества циклического алгоритма.

1. Простота использования и прозрач-

ность для понимания.

2. Минимальные размеры кода и данных.

Кроме того, в отличие от алгоритмов с

вытеснением, для всех задач необходим

только один стек.

К недостаткам циклического алгоритма

можно отнести отсутствие приоритетности и

очередей. К тому же задачи вызываются

независимо от того, должны ли они в данный

момент что-либо делать или нет, а на

прикладного программиста ложится

максимальная ответственность за

работоспособность системы.

Кооперативная многозадачность – это

еще один алгоритм переключения задач.

Задача, получившая управление,

выполняется до тех пор, пока она сама по

своей инициативе не передаст управление

другой задаче.

Приоритетная многозадачность с

вытеснением – это, по-видимому, наиболее

часто используемый в ОС РВ принцип

планирования. Основная идея состоит в том,

что высокоприоритетная задача как только

для нее появляется работа, немедленно

прерывает низкоприоритетную.

Необходимо отметить, что в одной

вычислительной системе могут одновременно

сосуществовать задачи и «жесткого», и

«мягкого» реального времени, и что только

одна из этих задач, обладающая наивысшим

приоритетом, может быть по-настоящему де-

терминированной.

Как правило, разработчики стараются

свести свою систему реального времени к

наиболее простым конфигурациям,

характерным для систем «жесткого»

реального времени, иногда даже в ущерб

эффективности использования

вычислительных ресурсов. Часто в системе

реализуется несколько «режимов» работы,

каждый из которых имеет свой набор вы-

полняемых задач с заранее заданными

приоритетами. Значительная часть особо

ответственных систем по-прежнему

реализуется без применения коммерческих

ОС РВ вообще.

6. Синхронизация задач

Хотя каждая задача в системе как

правило, выполняет какую-либо отдельную

функцию, часто возникает необходимость в

согласованности (синхронизации) действий,

выполняемых различными задачами. Такая

синхронизация необходима, в основном, в

следующих случаях.

1. Функции, выполняемые различными

задачами, связаны друг с другом. Одна из

вариаций в этом случае – это когда задача

при определенных условиях порождает одну

или несколько новых задач.

2. Необходимо упорядочить доступ не-

скольких задач к разделяемому ресурсу.

3. Необходима синхронизация задачи с

внешними событиями. Как правило, для этого

используется механизм прерываний.

4. Необходима синхронизация задачи по

времени. Для решения этих вопросов в конеч-

ном счете используются специальные

аппаратные средства, называемые таймером.

7. Тестирование

Прежде чем устанавливать вашу сис-

тему реального времени, рекомендуется про-

верить ее работоспособность с помощью

интенсивных тестов. Это особенно важно для

сложных динамических систем. Во время

такого тестирования желательно

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

«тяжелые» режимы работы, аварийные

ситуации и т.п. При умозрительном анализе

простых систем следует осторожно

относиться к рекламной информации

разработчиков ОС РВ, которые из

коммерческих соображений показывают, как

правило, параметры для «лучшего случая».

8. Можно ли обойтись без ОС РВ?

по мере роста числа и сложности функ-

ций, которые необходимо выполнять, наличие

стандартных средств организации

параллельного выполнения задач, работы с

таймером, межзадачного обмена

информацией и т. п. могут существенно

повысить производительность программистов

и уменьшить число ошибок. Именно здесь

могут проявить свои положительные стороны

ядра и операционные системы реального

времени, как раз такие средства и

предлагающие.

9. Linux реального времени

У Linux много достоинств: открытость

кода; большое количество сопутствующего

программного обеспечения, пока в основном

ориентированного на серверные применения;

наличие неплохой документации на API-

интерфейс и ядро операционной системы;

работа на процессорах различных классов. В

данный момент эта ОС готова к стабильной

работе, а открытость ее исходных текстов и

архитектуры наряду с растущей

популярностью заставляет программистов

переносить свои наработки на многие

аппаратные платформы. Для задач реального

времени сообщество разработчиков Linux

активно применяет специальные расширения

– RTLinux, KURT и UTIME, позволяющие

получить устойчивую среду реального

времени. RTLinux представляет собой

систему "жесткого" реального времени, а

KURT (KU Real Time Linux) относится к

системам "мягкого" реального времени. Linux-

расширение UTIME, входящее в состав

KURT, позволяет добиться увеличения

частоты системных часов, что приводит к

более быстрому переключению контекста

задач.

10. Операционные системы реального

времени и Windows NT

Windows NT, предназначенная в

основном для классических приложений, не

является хорошей платформой для

поддержания обработки в реальном времени.

Тем не менее на ее базе можно все-таки

построить простую мягкую СРВ, время от

времени допускающую опоздания.

Следующие обстоятельства могут облегчить

построение СРВ на базе NT:

– загрузка CPU низка (DPC имеют

достаточно времени);

– критическая работа делается на

уровне DPC или на уровне ISR.

Но для жесткой СРВ использование

Windows NT невозможно – система реального

времени никогда не будет предсказуемой. Что

следует изменить в Windows NT, чтобы ее

можно было использовать в жестких СРВ?

a) Класс процессов реального времени

должен иметь больше уровней.

б) Необходимо решить проблему

инверсии приоритетов.

в) Время, затрачиваемое каждым

системным вызовом, должно быть

предсказуемо и известно.

г) Система прерываний должна быть

заменена целиком:

– DPC должны иметь много уровней

приоритетов;

– DPC должны быть вытесняемыми

более приоритетными DPC.

– драйверы от третьих фирм и

системные драйверы должны быть

настраиваемыми (уровни прерываний ISR,

уровни прерываний DPC) ;

– драйверы от третьих фирм должны

быть открыты для разработчиков, должно

быть известно по крайней мере

максимальное время, затрачиваемое на

работу ISR и DPC;

– должно быть известно время

маскирования прерываний.

11. Операционная система QNX

QNX – это первая коммерческая ОС,

построенная на принципах микроядра и

обмена сообщениями. Система реализована

в виде совокупности независимых (но

взаимодействующих через обмен

сообщениями) процессов различного уровня,

каждый из которых реализует определенный

вид сервиса.

Предсказуемость, означающую ее

применимость к задачам жесткого реального

времени. Ни одна версия Unix не может

достичь подобного качества, поскольку

нереентрабельный код ядра слишком велик.

Любой системный вызов в Unix может

привести к непредсказуемой задержке. То же

самое относится к Windows NT, где реальное

время заканчивается между ISR (первичный

обработчик прерывания) и DPC (вызов

отложенной процедуры).

Масштабируемость и эффективность,

достигаемую оптимальным использованием

ресурсов и означающую ее применимость для

встроенных систем. Можно иметь только тот

сервис или те модули, которые реально

нужны, причем это не требует серьезных

усилий и не порождает проблемы.

Расширяемость и надежность

одновременно, поскольку написанный вами

драйвер не нужно компилировать в ядро,

рискуя вызвать нестабильность системы.

Быстрый сетевой протокол FLEET,

прозрачный для обмена сообщениями,

автоматически обеспечивающий

отказоустойчивость, балансирование нагрузки

и маршрутизацию между альтернативными

путями доступа. Он не так универсален, как

TCP/IP, но гораздо проще в использовании и

эффективнее.

Богатый выбор графических подсистем,

включающий QNX Windows, X11R5 и Photon,

что позволяет разработчикам выбирать ту,

которая лучше подходит для их целей.

Существуют также некоторые

ограничения, связанные с ориентацией

системы на рынок встроенных систем

реального времени. Вот важнейшие из них:

– нет поддержки SMP;

– нет своппинга виртуальной памяти на

диск;

– неэффективная и нестандартная

поддержка нитей (threads);

– нет поддержки Java (как следствие

предыдущего пункта);

– нет поддержки отображения файлов в

память;

– многочисленные ограничения

файловой системы;

– нет поддержки Unix-domain sockets;

– слабые средства разграничения и

контроля доступа пользователей;

– отсутствие средств безопасности в

рамках собственного сетевого протокола.

12. Проект Neutrino

Еще до появления Windows 95,

стартовал проект создания совершенно новой

ОС, которая могла бы воплотить в себе

лучшие идеи, разработанные в теории

операционных систем. Этот проект получил

кодовое название "Neutrino", довольно удачно

отражающее его суть – очень маленькая и

неуловимо быстрая ОС.

глобальная цель проекта Neutrino –

создание POSIX-совместимой

масштабируемой ОС, пригодной для

построения систем реального времени на

самом широком спектре оборудования.

термин "Neutrino", если говорить конкретно,

применяется на данном этапе не ко всей ОС,

а лишь к ее микроядру. Neutrino представляет

собой значительно более совершенную

модель, выполняющую гораздо больше

функций, чем микроядро QNX, имея при этом

лучшую производительность и временные

характеристики. Улучшенное микроядро

позволило также вчетверо уменьшить размер

менеджера процессов (с 80 до 20 Кбайт).

Функции, включенные в микроядро, были

выбраны по принципу минимального

количества операций, необходимых для их

исполнения. Все относительно сложные

функции были вынесены во внешние модули.

По этой причине Neutrino остается достаточно

маленьким и простым и по-прежнему

оправдывает название "микроядра".

управление процессами и памятью не

является, строго говоря, функцией Neutrino –

это функция менеджера процессов ProcNto,

который, кроме этого, занимается поддержкой

пространства имен ввода/вывода

Сетевой сервис в Neutrino представлен

только протоколом TCP/IP. Разработчики

создали специальную версию стека для

встроенных систем – Micro TCP/IP, который

занимает всего около 40 Кбайт кода за счет

ряда ограничений. Для тех же, кому нужны

все возможности TCP/IP, например

динамическая маршрутизация, будет

предоставлен другой вариант, совместимый

на 100% с BSD-sockets. Файловая система в

Neutrino реализована иначе, чем в QNX.

Главное функциональное отличие –

улучшенная приспособленность к сменным

носителям. Теперь приложение обращается к

драйверу, который определяет тип файловой

системы (по сигнатурам) и динамически

загружает соответствующую файловую

систему, реализованную в виде разделяемой

библиотеки.

13. Современные индустриальные

системы, функционирующие в режиме

реального времени

Полагаться на людей нельзя – и

ответственность в критических приложениях

перекладывается на автоматику.

Автоматическое управление начиналось

с простых релейных схем, но теперь уровень

сложности задач предполагает опору на

цифровую обработку информации с

использованием практически всех

современных компьютерных технологий.

Наиболее интенсивно используются в

промышленных системах распределенные

системы управления, приложения на основе

ПК и электроника для авиационных моторов,

суммарно составляя 30% всех затрат в этой

области.

Другой аспект – процентное

распределение покупок по отраслям

промышленности. Можно отметить

следующие тенденции: увеличивается

присутствие ПК в промышленном управлении,

а по отраслям растут темпы автоматизации

машиностроения; в химическом производстве

динамика сохраняется; в нефтепереработке

заметно небольшое замедление.

14. Организация промышленных систем

В развитии промышленных систем

автоматизации в основном просматривались

общие тенденции компьютерной индустрии,

однако можно указать несколько

принципиальных особенностей, которые

требуют специализированных решений.

1. Промышленные системы

функционируют в тяжелых для электронной

техники условиях внешней среды, поэтому по

сравнению с обычными компьютерами они

должны иметь повышенную термо-, вибро-,

ударопрочность.

2. Требуется подключать гораздо более

широкую номенклатуру внешних устройств.

3. Время реакции системы на изменения

параметров объекта управления

определяется внешними реальными

временными интервалами – такие системы

называются системами реального времени.

15. Аппаратная архитектура

Для разработчиков систем

автоматизации стандарты – это возможность

создавать открытые модульные комплексы из

готовых программных и аппаратных блоков

разных производителей. Выигрывают и

поставщики – во-первых, они могут

действовать на всем рынке, а не только на

своей частной делянке. Во-вторых, они

получают доступ к профессионально

разработанным спецификациям открытых

стандартов, для которых не требуется

приобретение патентов и которые не

защищены авторским правом.

Успех стандарта не определяется

постановлением правительства. Он будет

продуктивен при условии, что его

поддерживают поставщики, разработчики и

потребители. И уж во всяком случае стандарт

должен развиваться, отражая постоянно

растущий потенциал базовых технологий. В

этом плане в области систем управления

жизнь кипит: при изобилии стандартов

разного уровня идет жесткая конкурентная

борьба альтернативных подходов.

16. Технологии VME и PCI

По отмеченным причинам одним из

основных архитектурных решений для систем

промышленной автоматизации является

магистрально-модульная архитектура, в

которой различные внешние блоки – модули

связываются между собой через общую

магистраль. Первым из получивших широкое

признание международных стандартов на

магистрально-модульные системы стал

принятый в 1968 году стандарт CAMAC.

Сегодня уже очевидно, что большинство

разработчиков систем промышленной

автоматизации практически отказались от

применения нестандартных технических

решений (их доля снизилась до 12%),

возможно даже в ущерб техническим

характеристикам, ориентируясь на стандарты

де-факто и де-юре.

17. Мезонинные технологии

Мезонинные технологии применяются

достаточно давно: в середине 80-х не было

способа запаивать на основной плате

кристаллы памяти емкостью более 64 Кбайт,

и для увеличения ее объема использовались

мезонинные модули. Сейчас, когда степень

интеграции микросхем гораздо выше, на

одной плате размещается простой компьютер

со всеми соответствующими электронными

атрибутами, и еще остается место.

Мезонинные технологии приобрели новый

смысл – сегодня это средство модульного

наращивания функциональных возможностей.

Взяв за основу типовую плату, разработчик

может добавить к ней специальные

пользовательские функции, реализованные в

готовом мезонинном модуле.

Таким образом, мезонинные платы

представляют еще один, более низкий по

сравнению, например, с модулями VMEbus

уровень модульности. Типичный размер

мезонинных плат 50×80 мм. Они являются

функционально законченными изделиями и

устанавливаются на плату-носитель

18. Полевые системы

Для связи с удаленными цифровыми

устройствами промышленного назначения

принято использовать бит-последовательные

промышленные или полевые шины.

PROFIBUS-FMS представляет собой решение

для задач взаимодействия на цеховом и

полевом (field) уровне иерархии

промышленных связей: с его помощью

организуется обмен между

интеллектуальными field-устройствами и

контроллерами, а также между

контроллерами. Как правило, на этом уровне

обмен информацией осуществляется по

запросу прикладного процесса и не является

циклическим. Поэтому время реакции здесь

не очень существенно, гораздо важнее

функциональные возможности.

Модель PROFIBUS позволяет

определить коммуникационные связи,

объединяющие распределенные прикладные

процессы в один общий. Та часть

прикладного процесса field-устройства,

которая отвечает за взаимодействие,

называется виртуальным field-устройством

(VFD). Все объекты реального устройства, с

которыми можно взаимодействовать

(переменные, программы, диапазоны

данных), называются объектами

коммуникации. Отображение функций VFD на

реальное устройство обеспечивается в

коммуникационной модели PROFIBUS

интерфейсом прикладного уровня. Для этого

объекты коммуникации PROFIBUS-станции

вводятся в ее локальный словарь объектов –

OD. Конфигурация OD может определяться и

загружаться в устройство либо его

производителем, либо разработчиком или

может формироваться динамически. OD

содержит структуру и типы всех объектов, а

также их внутренние адреса в устройстве и

представление на шине (индекс/имя). Доступ

к объектам при функционировании

происходит через сервисные функции

протокола PROFIBUS-FMS, которые

позволяют, например, опросить/установить

значения переменных и массивов, запустить/

остановить программу.

19. Программное обеспечение

промышленных систем

Как показала практика, стоимость

создания систем промышленной

автоматизации определяется в основном

затратами на разработку ПО, доля которого

может доходить до 60%.

Чем располагает разработчик

промышленной системы? В первую очередь

это операционные системы,

поддерживающие функционирование

разрабатываемого приложения. В сфере

промышленной автоматизации свой мир

операционных систем – ОС реального

времени (ОС РВ). Конечно, можно создать ПО

системы автоматизации, опираясь только на

общецелевые средства, однако цена такой

разработки будет очень высока. Системы

автоматизации – это такая же прикладная

область, как, например, графика или САПР, и

кроме универсального здесь нужен

специализированный инструментарий.

20. Управление производством

Верхний уровень в комплексе

FactorySuite занимает пакет InTrack –

инструментарий для разработки систем

управления производством. Продолжая

линию, заложенную в пакете InTouch, он

поддерживает объектно-ориентированный

стиль разработки и имеет архитектуру клиент/

сервер. Назначение InTrack – создание

интерактивных приложений, способных

контролировать и управлять всеми стадиями

производственных процессов – от загрузки

сырья до выпуска готовой продукции.

Основные принципы в InTrack такие же,

как и в InTouch, – работа с переменными,

графическими образами и обработка

предупредительных сообщений. Добавлено

понятие схемы производственных процессов

как некоторой последовательности операций.

Схемы создаются в специальном

графическом редакторе из графических

образов, поставляемых в библиотеке InTrack.

Среди них производственные цепочки и

операции, материальные ресурсы, продукты.

В результате приложение, разработанное в

InTrack, способно автоматизировать сбор

данных и выдавать управляющие

воздействия на производственные процессы

в масштабах целого предприятия.

21.UML проектирование систем реального

времени

Сравнительно недавно появившийся

унифицированный язык моделирования

(UML) предлагает стандартизованную

нотацию для описания объектно-

ориентированных моделей [16, 18, 19, 21].

Объе-динение концепций объектно-

ориентированного проектирования с

концепциями параллельного выполнения

необходимо для успешного создания

распределенных приложений, работающих в

реальном масштабе времени. Поскольку UML

содержит стандартную нотацию для описания

объектно-ориентированных моделей, будем

использовать именно этот язык. Особое

внимание уделим моделированию динамики

системы, представляющему интерес для

приложений реального времени и

распределенных приложений.

22. Объектно-ориентированные методы и

UML

Объектно-ориентированные методы

основаны на концепциях сокрытия ин-

формации, классов и наследования [27].

Сокрытие информации [23] позволяет

получить замкнутые, а оттого в большей

степени поддающиеся модификации и

сопровождению системы. Наследование [27]

– это систематический способ адаптации

классов.

Язык UML, пришедший на смену

многочисленным системам нотации и мето-

дикам проектирования предложил нотацию

для описания объектно-ориентированных

моделей, которая стала промышленным

стандартом. Однако для эффективного

применения нотации UML необходимо

сочетать ее с каким-либо методом объектно-

ориентированного анализа и проектирования.

23. Метод и нотация

Метод проектирования и нотация

проектирования – это разные вещи. Нотация

проектирования ПО предназначена для

описания самого проекта. Хотя она и

предполагает наличие определенного

подхода к проектированию, сам подход

остается за ее рамками. Метод

проектирования ПО представляет собой

систематическое описание этапов создания

проекта.

Нотация проектирования ПО

описывает.проект программы в графическом

или текстовом виде. В частности, диаграммы

классов – это графическая нотация, а

псевдокод – текстовая.

Концепция проектирования ПО – это

фундаментальная идея, применимая к

проектированию всей системы, например

сокрытие информации.

Стратегия проектирования ПО – общий

план и методика выполнения проекта. Одной

из стратегий является объектно-

ориентированная декомпозиция.

Критерии структурирования ПО – это

эвристические или формальные правила,

помогающие проектировщику разбить

систему на отдельные компоненты. Так,

критерии разбиения на объекты - это правила

декомпозиции системы на объекты.

Метод проектирования ПО описывает

последовательность шагов, выполняемых при

работе над проектом при условии, что

требования к системе уже сформулированы.

Он помогает выявить, какие решения

предстоит принять, в каком порядке это

следует делать и на основе каких критериев.

Метод проектирования базируется на наборе

соответствующих концепций, использует одну

или несколько стратегий, а также ту или иную

нотацию для документирования результатов.

При выполнении определенных шагов метод

может подсказать разработчику, какие

критерии наиболее удобны для декомпозиции

системы.

24. Системы и приложения реального

времени

Системы реального времени (рис. 5.1) –

это параллельные системы с временными

ограничениями. Они широко распространены

в промышленных, коммерческих и военных

приложениях. Термин «система реального

времени» обычно относится к системе в

целом, включающей приложение реального

времени, операционную систему реального

времени и подсистему ввода/вывода

реального времени. В состав такой системы

входят также драйверы специальных

устройств, управляющие работой различных

датчиков и приводов. Поскольку здесь речь

идет в основном о проектировании

приложений, мы будем пользоваться терми-

ном «приложение реального времени», а не

«система реального времени». Однако в этом

разделе приложения реального времени

рассматриваются в более широком контексте

систем реального времени.

Рис. 5.1. Система реального времени

25.Обзор нотации UML . Диаграммы UML.

Диаграммы прецедентов. Нотация UML

для классов и объектов

В методе COMET используется нотация

из унифицированного языка моделирования

UML, которая объединила нотации,

предложенные Бучем, Джекобсоном, Рамбо и

Харелом.

Co временем нотация UML

расширялась, и теперь в ней поддерживается

много различных диаграмм.

В нотации UML поддерживаются девять

видов диаграмм:

– диаграммы прецедентов;

– диаграммы классов;

– диаграммы объектов, являющиеся

вариантом диаграмм классов в применении к

экземплярам. В методе COMET вместо них

работают консолидированные диаграммы

кооперации;

– диаграммы кооперации;

– диаграммы последовательности;

– диаграммы состояний;

– диаграммы деятельности (в COMET не

используются);

– диаграммы компонентов (в COMET не

используются)– диаграммы развертывания.

Актер (actor) инициирует прецедент.

Прецедент (use case) описывает после-

довательность взаимодействий между

актером и системой. Актер изображается на

диаграмме прецедентов в виде фигуры

человечка, система – в виде прямоугольника,

прецедент – в виде эллипса внутри этого

прямоугольника. Коммуникационные

ассоциации связывают актеров с теми

прецедентами, в которых они участвуют.

Между прецедентами могут быть отношения

include (включает) и extend (расширяет).

Для того чтобы отличить класс (тип) от

объекта (экземпляра типа), имя объекта под-

черкивается. Объект может обозначаться как

anObject , anotherObject : Class или : Class .

Классы и объекты встречаются в разных

диаграммах UML.

26. Диаграммы классов

На такой диаграмме классы

изображаются в виде прямоугольников, а

статические (постоянные) отношения между

ними – в форме дуг. Поддерживаются три

основных типа отношений между классами:

– ассоциации. Ассоциация между двумя

классами (бинарная ассоциация)

изображается в виде линии, соединяющей

прямоугольники классов. У нее есть имя и,

возможно, стрелка, поясняющая, в каком

направлении следует это имя читать. На

каждом конце ассоциации проставляется

кратность – число, свидетельствующее,

сколько экземпляров одного класса связано с

одним экземпляром другого класса.

Дополнительно на каждом конце ассоциации

может присутствовать стрелка, указывающая

направление навигации вдоль данной

ассоциации.

– иерархии агрегирования и композиции.

Это отношения вида целое/часть. Отношение

композиции (изображается закрашенным

ромбом) накладывает более сильные

ограничения на экземпляры классов, чем

отношение агрегирования (показывается

незакрашенным ромбом). Ромб одной

вершиной примыкает к прямоугольнику

класса, являющегося частью в отношении

вида «часть/целое»;

– иерархия обобщения/специализации.

Это отношение вида «является». Обобщение

изображается в виде стрелки, ведущей от

подкласса (потомка) к суперклассу

(родителю), причем стрелка упирается в

прямоугольник суперкласса.

Видимость определяет, доступен ли

элемент класса вне самого класса.

Показывать видимость на диаграмме

необязательно. Открытая видимость, изобра-

жаемая символом + (плюс), означает, что

элемент виден извне класса.

Закрытая видимость, отмеченная знаком

– (минус), свидетельствует о том, что элемент

виден только внутри класса, в котором он

определен, а от других классов скрыт. За-

щищенная видимость, показываемая знаком

#, говорит о том, что элемент виден внутри

класса, в котором определен, а также во всех

подклассах этого класса.

27. Диаграммы взаимодействия

В UML есть два вида диаграмм

взаимодействия: диаграммы кооперации (col-

laboration diagram) и диаграммы

последовательности (sequence diagram).

Семантически они эквивалентны.

Диаграммы кооперации. На диаграмме

кооперации показывается, как объекты

динамически общаются между собой,

посылая и получая сообщения. Эта

диаграмма представляет структурную

организацию взаимодействующих объектов,

изображаемых в виде прямоугольников и

соединяющих их дуг.

Помеченные стрелки рядом с дугами

обозначают имя сообщения и направление

его передачи между объектами. Отдельные

сообщения в последовательности сообщений,

отправляемых от одного объекта к другому,

нумеруются.

Диаграмма кооперации в нотации UML

Диаграммы последовательности. Другой

способ показать взаимодействие объектов –

воспользоваться диаграммой

последовательности. Диаграмма

последовательности двумерна: участвующие

объекты изображаются вдоль горизонтальной

оси, а время откладывается вдоль

вертикальной. От прямоугольника каждого

объекта идет вниз вертикальная пунктирная

линия, называемая линией жизни. Период, в

течение которого объект выполняет

операцию, именуется активизацией. На

протяжении этого периода линия жизни

изображается двойной сплошной линией.

Актер обычно изображается в левом

верхнем углу диаграммы. Помеченные

горизонтальные линии представляют

пересылку сообщений. Существенны только

отправитель и получатель сообщения.

Сообщение посылается объектом-отпра-

вителем объекту-получателю. Время

возрастает в направлении сверху вниз.

Расстояние по вертикали между

сообщениями не имеет значения.

28. Диаграммы состояний

В нотации UML диаграмма перехода

состояний называется диаграммой состояний.

На ней состояния представляются

прямоугольниками со скругленными углами, а

переходы – соединяющими их дугами (рис.

6.7). Начальное состояние обозначается

дугой, исходящей из маленького

закрашенного кружка. Может также

присутствовать необязательное конечное

состояние, изображаемое закрашенным

кружком внутри незакрашенного (иногда его

называют «бычий глаз»). Диаграмму

состояний разрешается подвергнуть

иерархической декомпозиции, так что

надсостояние разлагается на подсостояния.

Рядом с дугой, представляющей

переход, находится условие перехода в виде:

Событие [условие]/Действие. Событие

вызывает переход в новое состояние. Если

задано необязательное булевское условие,

то переход осуществится, когда оно истинно.

В результате перехода может быть

выполнено необязательное действие.

Дополнительно с состоянием иногда

ассоциируются:

– действие при входе в состояние;

– деятельность, выполняемая во время

нахождения внутри состояния;

– действие при выходе из состояния.

29. Пакеты

В UML пакетом называется группа

элементов модели, используемая, например,

для представления системы или подсистемы.

Такая группа изображается пиктограммой

папки – большим прямоугольником, над

которым находится прямоугольник поменьше.

Пакеты бывают вложенными; между ними мо-

гут существовать отношения зависимости и

обобщения/специализации. Пакеты способны

содержать классы, объекты или прецеденты.

Нотация UML для пакетов

30. Диаграммы параллельной кооперации

Будем называть активный объект

задачей, а пассивный – просто объектом.

Задачи отмечаются на диаграммах

параллельной кооперации, которые

позволяют наглядно представить

параллелизм в системе. На такой диаграмме

задача показывается в виде прямоугольника

с жирной границей, а пассивный объект – в

виде прямоугольника с тонкой границей

(здесь представлена также нотация для

множества объектов, возникающих при

порождении нескольких объектов одного

класса).

Рис. 6.10. Нотация UML для активных и

пассивных объектов

Обмен сообщениями на диаграммах

параллельной кооперации. Интерфейс для

обмена сообщениями на диаграмме

параллельной кооперации может быть слабо

связанным (loosely coupled) или сильно

связанным (tightly coupled). В последнем

случае производитель посылает сообщение

потребителю и ожидает немедленного

подтверждения. Сильно связанный обмен

бывает двух видов: сильно связанный обмен

сообщениями с ответом и сильно связанный

обмен сообщениями без ответа.

31. Диаграммы развертывания

На диаграмме развертывания

очерчивается физическая конфигурация

системы, то есть физические узлы и

соединения между ними (например,

связывающая их сеть). Узел представляется

в виде куба, а соединение – в виде линии,

ведущей от одного куба к другому. По сути,

диаграмма развертывания – не что иное, как

диаграмма классов с акцентом на узлах

системы [16].

Узлом, как правило, является

компьютер, при этом максимальное число

экземпляров узла может быть ограничено (см.

раздел 6.10). Для физического соединения

имеется стереотип, задающий

32. Механизмы расширения UML

В UML имеется три механизма

расширения языка [16]:

– стереотипы. Стереотип определяет

новый строительный блок, производный от

существующего в UML элемента

моделирования, но адаптированный к

решаемой задаче. В UML определено

несколько стандартных стереотипов, но

проектировщик может создавать и собствен-

ные. Названия стереотипов заключаются в

кавычки.

– помеченные значения. Помеченное

значение расширяет свойства строительного

блока UML, сообщая тем самым новую

информацию. Оно заключается в фигурные

скобки {метка = значение}. Друг от друга

помеченные значения отделяются запятыми.

– ограничения. Ограничение задает

условие, которое должно выполняться. В UML

ограничение семантически расширяет

элемент, добавляя новые правила или

изменяя существующие.

33. Технологии параллельных и

распределенных систем

Рассмотрим технологию (или

инфраструктуру) параллельной и

распределенной обработки, которая нужна в

приложениях реального времени.

Инфраструктуру обеспечивают операционная

система, вычислительная сеть и программное

обеспечение (ПО) промежуточного слоя.

34. Среды для параллельной обработки

Основные среды для параллельной

обработки можно отнести к следующим

категориям: мультипрограммные среды,

симметричные мультипроцессорные среды и

распределенные среды.

Мультипрограммная среда. В

мультипрограммной (или многозадачной)

среде несколько задач разделяют

единственный процессор. Виртуальный

параллелизм обеспечивается операционной

системой, которая управляет выделением

процессора отдельным задачам, так что

создается иллюзия, будто у каждой задачи

есть свой процессор.

Симметричная мультипроцессорная

среда. В симметричной мультипроцессорной

среде есть два или несколько процессоров с

общей памятью. Для всех процессоров

существует единое физическое адресное

пространство, поэтому все процессы

находятся в общей памяти. В такой среде

поддерживается реальный параллелизм,

поскольку процессоры работают

одновременно.

Распределенная среда. На рис.7.3

показана типичная распределенная среда,

где есть несколько узлов, связанных между

собой сетью. Каждый узел – это компьютер с

собственной локальной памятью, который

обычно представляет собой

мультипрограммную (см. рис.7.1) или

симметричную мультипроцессорную (см.

рис.7.2) среду. Кроме того, в каждом узле

имеется сетевая карта. Важным отличием

распределенной среды является то, что у

узлов нет общей памяти. Следовательно,

распределенное приложение состоит из

параллельных процессов, работающих в

разных узлах. Каждый процесс может иметь

несколько потоков, исполняемых в том же

узле. Поскольку разделяемой памяти нет, то

процессы в разных узлах должны

обмениваться информацией, посылая

сообщения по сети.

Распределенная среда

35. Поддержка исполнения в

мультипрограммной и

мультипроцессорной средах

Поддержка исполнения параллельных

вычислений реализуется:

– ядром операционной системы. Оно

предоставляет сервисы, необходимые для

параллельной обработки. В некоторых

современных операционных системах

минимальную поддержку дает микроядро, а

все остальное – системные задачи;

– системой времени исполнения в языке

программирования, поддерживающем

параллелизм;

– пакетом для поддержки потоков.

Предоставляет сервисы, необходимые для

управления потоками (облегченными

процессами) внутри тяжеловесного процесса.

36. Планирование задач

В системе с одним процессором ядро

операционной системы должно планировать

доступ параллельных задач к процессору.

Ядро поддерживает список готовых к работе

задач. Для назначения центрального

процессора (ЦП) задачам было разработано

много разных алгоритмов, в том числе

циклическое обслуживание и вытесняющее

планирование с приоритетами.

Алгоритмы планирования задач. Цель

циклического алгоритма планирования –

обеспечить справедливое выделение

ресурсов. Задача ставится в очередь,

поддерживающую принцип «первым пришел

– первым обслужен» (FIFO).

Для систем реального времени

циклическое планирование не годится.

Задачам нужно назначать приоритеты в

соответствии с важностью выполняемых

операций. Так, критичные по времени задачи

обязательно должны уложиться в отведенные

временные рамки. Поэтому для систем

реального времени больше подходит

алгоритм вытесняющего планирования с

приоритетами. Каждой задаче назначается

приоритет, и список готовых упорядочивается

по значению этого приоритета. ЦП

выделяется задаче с наивысшим

приоритетом. Затем эта задача выполняется

до тех пор, пока не приостановится сама либо

не будет вытеснена задачей с большим

приоритетом (которая только что

возобновила работу). Задачам с одинаковыми

приоритетами ЦП выделяется по

циклическому алгоритму.

Контекстное переключение задач. Если

задача приостанавливается из-за блокировки

или потому что ее вытеснили, необходимо

сохранить текущий контекст, то есть

состояние процессора. Сюда относятся

аппаратные регистры, счетчик команд задачи

(который указывает на следующую команду,

подлежащую выполнению) и другая

информация. Когда задача снова получит ЦП,

контекст требуется восстановить. Эта

последовательность операций называется

контекстным переключением.

В мультипроцессорной среде с

разделяемой памятью копия ядра обычно вы-

полняется на каждом процессоре. Процессор

выбирает задачу, находящуюся в начале

списка готовых. Взаимно исключающий

доступ к списку обеспечивает аппаратный

семафор, который обычно реализуется с

помощью команды Test and Set Lock

(проверить и установить замок). Таким

образом, одна и та же задача может в разные

моменты времени исполняться на разных

процессорах. В некоторых

мультипроцессорных средах потоки одного

многопоточного процесса могут параллельно

выполняться на разных процессорах.

37. Вопросы ввода/вывода в

операционной системе

Рассмотрим способы, которые

операционная система применяет для работы

с устройствами ввода/вывода. Существует

два механизма выполнения ввода/вывода:

прерывания и опрос. Рассмотрим как

параллельные задачи взаимодействуют с

внешними устройствами.

Устройства ввода/вывода общаются с

операционной системой при помощи кон-

троллеров, которые находятся на

интерфейсных платах устройства).

Центральный процессор работает именно с

контроллером, а не с самим устройством. У

контроллера есть набор регистров,

используемых для обмена информацией с

ЦП. В некоторых компьютерах имеются

специальные команды для доступа к

регистрам контроллера. Если же применяется

отображение устройств на память, то

регистры контроллера представляются в виде

обычных ячеек адресного пространства.

Если ввод/вывод управляется

прерываниями, то при поступлении входных

данных и завершении операции вывода

генерируется прерывание. Есть множество

способов, но наиболее распространены ввод/

вывод с управлением от программы и

ввод/вывод, запускаемый программой. В

первом случае прерывание обычно

генерируется после чтения или записи

каждого символа, во втором между

устройством ввода/вывода и основной

памятью помещается устройство прямого

доступа к памяти (Direct Memory Access –

DMA), управляющее передачей блоков

данных между ними. По завершении

передачи устройство DMA генерирует

прерывание. . Когда используется ввод/вывод

с опросом, прерывания отсутствуют. Поэтому

система должна периодически проверять

устройство ввода, чтобы понять, не пришли

ли новые данные, или устройство вывода,

чтобы выяснить, завершилась ли операция.

38. Технологии клиент-серверных и

распределенных систем

Распределенные приложения

исполняются на географически разнесенных

узлах, соединенных локальной или

глобальной сетью. Типичные примеры – при-

ложения клиент-сервер, распределенные

приложения сбора данных в реальном

времени и распределенные приложения,

занимающиеся управлением.

Клиент-серверная система логически

состоит из двух компонентов: клиента,

который запрашивает сервисы, и сервера,

который эти сервисы предоставляет. Таким

образом, сервер выступает в роли

производителя, а клиент – в роли потре-

бителя сервисов. Клиент-серверная система

– это распределенное приложение, в котором

клиент и сервер (или серверы) географически

удалены друг от друга (рис. 7.6). Сеть,

соединяющая клиентов с серверами, может

быть локальной или глобальной. Клиент

посылает серверу запрос по сети. Сервер

выполняет этот запрос и возвращает клиенту

результаты.

39. Технология World Wide Web

Огромная популярность Всемирной

паутины (WWW), придуманной Бернер-сом-Ли

из Европейской организации по ядерным

исследованиям (CERN) в Женеве привела к

очень быстрому росту сети Internet. Страницы

WWW размещены на Web-серверах. Каждая

страница обычно содержит графику и ссылки

на другие страницы.

Web-страница создается с помощью

языка разметки, например широко рас-

пространенного языка HTML (Hyper Text

Markup Language – язык разметки ги-

пертекста) или начавшего приобретать

популярность языка XML (eXtensible Markup

Language – расширяемый язык разметки).

Каждая страница помечается

унифицированным указателем ресурса (URL),

который используется в составе любой

ссылки на эту страницу. Когда пользователь

хочет просмотреть страницу, браузер берет

из URL адрес сервера и обращается к нему с

просьбой загрузить необходимые данные

Внешний модуль, или вставка (plug-in), –

это программа, которая помещается в

браузер и расширяет его возможности –

скажем, позволяет обрабатывать аудио- и

видеоданные, посылаемые сервером.

Внешний модуль может входить в дистри-

бутив браузера или загружаться отдельно с

определенного сервера.

С появлением WWW и Web-браузеров в

начале 90-х годов браузер стал рас-

пространенным пользовательским

интерфейсом для распределенных приложе-

ний. Рост популярности Всемирной паутины

вывел на авансцену язык программирования

Java, который широко применяется для

создания апплетов.

40. Сервисы распределенных

операционных систем

Распределенная система состоит из

компьютеров, соединенных коммуни-

кационной средой, например локальной

сетью. В распределенной среде желательно

обеспечить независимость сервисов от

местоположения. Это значит, что компонент,

желающий послать сообщение другому

компоненту, не обязан знать, где находится

адресат. При наличии службы именования

сервер имен хранит имена глобальных сер-

висов. Предполагается, что местоположение

самого сервера имен хорошо известно. Если

клиент хочет получить доступ к некоторому

сервису, он запрашивает информацию о нем

у сервера имен.

Пример службы имен – это система

доменных имен (DNS), используемая в сети

Internet.

Связывание клиентов и серверов.

Термин связывание относится к ассоциации

между клиентом и сервером. Статическое

связывание выполняется на этапе

компиляции и означает, что все обращения

клиента к серверу жестко «зашиты» в код.

Динамическое связывание производится

во время выполнения. Оно характеризуется

большей гибкостью, чем статическое, но

меньшей эффективностью. Для

динамического связывания необходимо

указать имя сервера, который ведет спра-

вочник имен и адресов серверов. Каждый

сервер регистрирует свое местоположение и

предоставляемые сервисы у сервера имен.

Клиент посылает запрос серверу имен,

передавая имя серверного объекта, и

получает ссылку на него. Затем эта ссылка

используется для доступа к удаленному

серверу.

Прозрачный обмен сообщениями между

распределенными задачами можно

реализовать с помощью распределенного

ядра распределенной операционной системы.

В тех распределенных приложениях, где

число задач относительно постоянно, каждое

распределенное ядро также может содержать

собственную копию этой таблицы. На стадии

начальной загрузки системы распределенное

ядро посылает запрос серверу имен с

просьбой загрузить таблицу имен.

Сервисы сокетов. Сокеты – это

интерфейс прикладных программ (API),

предоставляемый многими операционными

системами. Он определяет набор операций,

доступных приложению для организации

обмена данными по сети с другим

приложением по заданному протоколу,

например TCP/IP.

Обмен сообщениями через порты. В

некоторых распределенных системах обмен

сообщениями между удаленными узлами

реализован с помощью портов, что позволяет

максимально ослабить связанность.

Компонент (процесс или поток) в одном узле

посылает сообщение, не указывая явно имя

получателя, а задавая выходной порт.

Компонент-получатель забирает сообщения

из своего входного порта.

41. ПО промежуточного слоя

Распределенным системам часто

приходится работать в гетерогенных средах,

когда в разных узлах установлено различное

оборудование и операционные системы. ПО

промежуточного слоя – это слой

программного обеспечения, располагаемый

поверх ОС с целью создания однородной

платформы, на которой могут

функционировать распределенные при-

ложения. . Изначально платформы для

распределенных вычислений базировались

на модели клиент-сервер. Но в последнее

время все большую популярность завое-

вывает объектная модель. В объектной

модели объекты получают глобальные имена

и могут вызываться непосредственно на

сервере. Некоторые распределенные

системы поддерживают механизм вызова

удаленных процедур (RPC). Клиент в одном

узле запрашивает удаленную процедуру

сервера, находящегося в другом узле. Вызов

удаленной процедуры аналогичен вызову

локальной процедуры, поэтому тот факт, что

сервер находится далеко, скрыт от клиента.

42. Стандарт CORBA

CORBA (Common Object Request Broker

Architecture – единая архитектура брокера

объектных запросов) – это стандарт открытых

систем, разработанный группой Object

Management Group (OMG), который

обеспечивает взаимодействие между

объектами на гетерогенной платформе.

Брокер объектных запросов (ORB) выполняет

функции ПО промежуточного слоя,

поддерживающего отношения вида клиент-

сервер между распределенными объектами.

Серверные объекты предоставляют сервисы,

которые клиенты могут запрашивать с

помощью ORB. В общем случае клиенты и

серверы - это всего лишь роли объектов.

Таким образом, объект способен выступать в

роли клиента в отношениях с одним объектом

и в роли сервера – в отношениях с другим. С

помощью ORB клиентский объект в состоянии

вызывать операции серверного объекта, не

зная, где тот находится, на какой платформе

(аппаратной или программной) исполняется,

какие коммуникационные протоколы нужны

для связи с ним и на каком языке он написан.

Сервисы CORBA. Брокер объектных

запросов позволяет клиенту прозрачно

вызывать операцию серверного объекта,

предоставляя службу имен. Когда создается

объект CORBA, ему присваивается

уникальная объектная ссылка. Получить

ссылку можно с помощью просмотра

каталога. Иными словами, служба имен

CORBA дает ссылку на поименованный

объект, а клиент затем вызывает операцию

этого объекта. Служба имен включает такой

сервис каталогов, который аналогичен

телефонному каталогу «белые страницы».

Другой сервис, предоставляемый

CORBA, – это трейдинг. Он позволяет по-

лучить ссылку на объект путем

сопоставления характеристик известных

объектов (например, типа обслуживания) с

характеристиками, посланными клиентом.

Сервис трейдинга, следовательно, сводится к

сервису каталогов, аналогичному

телефонным «желтым страницам».

43. Другие компонентные технологии

Технология СОМ. DCOM – это

предложенная Microsoft распределенная

объектная технология, построенная на основе

архитектуры СОМ (Component Object Model –

компонентная модель объектов). СОМ

предоставляет каркас для взаимодействия

приложений в среде Windows. DCOM

позволяет клиенту общаться с компонентом,

находящимся в удаленном узле,

перехватывая вызовы клиента и переадресуя

их серверу. И СОМ, и CORBA включают язык

IDL, но CORBA задумана как стандарт, тогда

как СОМ – патентованная технология,

работающая только на платформе Windows.

Компоненты ActiveX – это исполняемые

программы, которые согласуются со

стандартом Microsoft СОМ и функционируют

на платформе Windows. Их можно загрузить и

выполнить внутри СОМ-совместимых контей-

неров. Примером такого контейнера служит

Web-браузер Internet Explorer.

Технология JavaBeans. JavaBeans

представляет собой компонентную

технологию на базе языка Java,

предназначенную для специализированных

приложений. JavaBeans – это компоненты

пользовательского интерфейса на стороне

клиента, a Enterprise JavaBeans – компоненты

на стороне сервера. Bean-компонент,

состоящий из набора классов и ресурсов.

Технология Jini. Jini (Java Intelligent

Network Infrastructure – сетевая

интеллектуальная инфраструктура Java) – это

технология соединения для встроенных

систем и сетевых приложений, цель которых

– упростить взаимодействие компьютеров и

других устройств. Jini предназначена для

сотовых телефонов, цифровых камер,

телевизоров и видеомагнитофонов. Она

использует технологию Java, а устройства

соединяются посредством Java RMI.

44. Системы обработки транзакций

Приложения для обработки транзакций

(или просто транзакционные приложения)

относятся к классу критических для бизнеса

или иной деятельности [14]. Сюда входят

системы ввода заказов, резервирования

авиабилетов и кассовые терминалы.

Транзакционное приложение занимается

обновлением информации в базе данных.

Транзакция – это запрос клиента к серверу,

состоящий из двух или более операций,

которые образуют единую логическую

функцию, причем она должна быть либо

выполнена полностью, либо не выполнена

вовсе. Транзакции порождаются клиентом и

посылаются серверу для обработки. В

классической конфигурации клиента и

сервера обработка целиком возлагается на

сервер. В распределенных приложениях

сервер может делегировать одну или

несколько операций другим серверам.

У транзакций выделяются следующие

свойства:

– атомарность. Транзакция – это

неделимая единица работы. Она либо вы-

полняется полностью (фиксируется), либо не

выполняется вовсе (откатывается);

– непротиворечивость. После

завершения транзакции система должна ока-

заться в непротиворечивом состоянии;

– изолированность. На поведение

транзакции не должны оказывать влияния

другие транзакции;

– долговечность, или устойчивость.

Изменения сохраняются после завершения

транзакции, даже если за ним последует сбой

системы.

45. Разбиение на задачи

На этапе проектирования подсистем

приложение разбивается на отдельные

подсистемы. При этом разрабатываются

параллельные задачи, о чем пойдет речь да-

лее, и скрывающие информацию классы, из

которых создаются пассивные объекты.

Важной целью, стоящей перед

разбиением на задачи и классы, является

разделение обязанностей. Задача применяет

сокрытие информации для инкапсуляции

аспектов параллелизма, в том числе деталей

синхронизации, управления, упорядочения и

коммуникации. Классы скрывают

информацию, чтобы инкапсулировать

структурные (статические) аспекты, такие как

информация об устройствах или абстракции

данных. На этапе разбиения на задачи

разрабатывается архитектура задач, то есть

перечень задач в системе, их интерфейсы и

способы общения. Для выявления задач

применяются критерии разбиения на задачи,

они помогают отобразить объектно-

ориентированную аналитическую модель

системы на параллельную многозадачную

архитектуру. Такие критерии представляют

собой набор эвристик или рекомендаций, в

которых аккумулирован практический опыт

специалистов по проектированию

параллельных систем и систем реального

времени.

46. Вопросы разбиения на параллельные

задачи

Задача – это активный объект, который

называют также процессом или потоком.

Слишком большое число задач может

чрезмерно усложнить систему из-за

необходимости заниматься межзадачными

коммуникациями и синхронизацией, а также

привести к неоправданным накладным

расходам на контекстные переключения.

Следовательно, проектировщик системы

обязан включать задачи с целью упрощения

проекта, не допуская появления слишком

большого их числа. В процессе разбиения на

задачи природа параллелизма

формализуется путем определения па-

раллельных задач и интерфейсов

коммуникации и синхронизации между ними.

Объекты, вошедшие в аналитическую

модель, рассматриваются с целью выяснить,

какие из них могут выполняться параллельно,

а какие – только последовательно. Объекты,

способные работать параллельно,

вычленяются в отдельные задачи. Объекты,

которые должны выполняться строго

последовательно, объединяются в задачу,

которая может охватывать один или

несколько объектов. Возможно также, что

одна задача будет вызывать одну операцию

некоторого объекта, а другая – другую

операцию того же объекта.

47. Категории критериев разбиения на

задачи

Критерии разбиения на задачи можно

отнести к нескольким категориям по признаку

участия в процессе структурирования:

– критерии выделения задач

ввода/вывода. Касаются отображения

объектов интерфейса устройств на задачи

ввода/вывода и вопроса о моменте активи-

зации таких задач;

– критерии выделения внутренних задач.

Связаны с тем, как внутренние объекты

отображаются на внутренние задачи и как эти

задачи активизируются;

– критерии назначения приоритетов

задачам. Позволяют определить отно-

сительную важность каждой задачи;

– критерии группировки задач.

Позволяют решить, какие объекты следует

группировать в параллельные задачи и как

именно;

– критерии инверсии задач.

Применяются для решения вопроса о том,

какие задачи стоит объединить для

уменьшения накладных расходов. Это можно

делать при исходном разбиении или при

пересмотре первоначального проекта.

Критерии разбиения применяются

поэтапно; сначала критерии выделения задач

ввода/вывода, критерии выделения

внутренних задач и назначения приоритетов.

В результате мы получаем взаимно-

однозначное соответствие между объектами

из аналитической модели и задачами из

проектной модели. Затем с целью

уменьшения числа задач используются

критерии группировки. Опытный проек-

тировщик может выполнять эти шаги

одновременно. После того как задачи выяв-

лены, определяются их интерфейсы.

48. Критерии выделения задач

ввода/вывода

Ниже описываются различные критерии

выделения задач ввода/вывода. Для этого в

первую очередь необходимо определить

характеристики устройства, интерфейс с

которым должна реализовшвать задача.

Характеристики устройств

ввода/вывода. Информация, относящаяся к

аппаратным особенностям устройств

ввода/вывода, обычно не отражается в

аналитической модели.

Асинхронные задачи интерфейса с

устройствами ввода/вывода. Если в системе

имеются асинхронные устройства

ввода/вывода, то для интерфейса с каждым

из них нужна отдельная задача, которая

будет активизироваться при поступлении

прерывания от устройства. В процессе

разбиения на задачи все объекты

интерфейса асинхронных устройств,

представленные в аналитической модели,

отображаются на соответствующие задачи.

Периодические задачи интерфейса с

устройством ввода/вывода. Если асинхронная

задача интерфейса с устройством

ввода/вывода работает с асинхронным

устройством, то периодическая задача имеет

дело с пассивным устройством, которое

необходимо время от времени опрашивать. В

этой ситуации задача активизируется

периодически, но ее функции связаны с

вводом/выводом.

49. Характеристики устройств

ввода/вывода.

характеристики устройств ввода/вывода.

Важно понять, является устройство

асинхронным (активным) или пассивным. Вот

три основных класса устройств ввода/вывода:

• асинхронные устройства ввода/вывода

(иногда их называют также активными),

работающие по прерываниям. Когда

асинхронное устройство ввода получает

данные для обработки, оно генерирует

прерывание. Асинхронное же устройство

вывода генерирует прерывание, когда

заканчивает операцию вывода и готово к

приему новых данных;

• пассивные устройства ввода/вывода.

Пассивное устройство не генерирует

прерываний при завершении операции.

Чтобы узнать, есть ли информация у

пассивного устройства ввода, его надо

периодически опрашивать. Соответственно

перед отправкой данных пассивному

устройству вывода надо убедиться, что оно

готово принять их;

• канал связи. Некоторые управляемые

микропроцессорами устройства ввода/вывода

и внешние системы подключаются с помощью

канала связи. Порядок обмена данными

между системами определяется коммуни-

кационным протоколом (например, TCP/IP).

На прикладном уровне задачи,

принадлежащие разным системам,

обмениваются сообщениями.

50. Асинхронные задачи интерфейса с

устройствами ввода/вывода.

. Если в системе имеются асинхронные

устройства ввода/вывода, то для интерфейса

с каждым из них нужна отдельная задача,

которая будет активизироваться при

поступлении прерывания от устройства. В

процессе разбиения на задачи все объекты

интерфейса асинхронных устройств,

представленные в аналитической модели,

отображаются на соответствующие задачи.

Асинхронная задача интерфейса с

устройством обязана работать с той же

скоростью, что и само устройство.

Асинхронная задача интерфейса с

устройством ввода/вывода – это задача

драйвера устройства. Как правило, она

активизируется низкоуровневым

обработчиком прерывания, а иногда

непосредственно устройством.

51. Периодические задачи интерфейса с

устройством ввода/вывода.

Если асинхронная задача интерфейса с

устройством ввода/вывода работает с

асинхронным устройством, то периодическая

задача имеет дело с пассивным устройством,

которое необходимо время от времени

опрашивать. В этой ситуации задача

активизируется периодически, но ее функции

связаны с вводом/выводом.

Такая задача запускается событием

таймера, выполняет операцию ввода/вывода,

после чего ждет следующего события

таймера. Период задачи – это промежуток

времени между последовательными

запусками.

О выборе временных интервалов для

периодических задач ввода/ вывода

Частота, с которой задача опрашивает

датчик, зависит от ожидаемой частоты из-

менения его показаний, а также от

приемлемой величины задержки извещения о

модификациях.

52. Пассивные задачи интерфейса с

устройствами ввода/вывода.

Такие задачи используются для работы с

пассивными устройствами ввода/ вывода,

которые не надо опрашивать. В частности,

они применяются в случае, когда желательно

совместить вычисления с вводом/выводом.

Обратите внимание, что слово «пассивное»

относится к устройству, а не к объекту.

Объект остается активным, поскольку

представляет собой задачу. Рассмотрим

следующие случаи:

– необходимо обеспечить совмещение

ввода от пассивного устройства с вы-

числительной задачей, которая получает и

обрабатывает данные. Это достигается с

помощью пассивной задачи интерфейса с

устройством, которая считывает данные по

запросу.

Отделение пассивной задачи ввода от

вычислительной задачи полезно только в тех

случаях, когда последняя должна произвести

некоторые вычисления за время, пока задача

ввода читает данные. Если же

вычислительная задача должна дожидаться

входных данных, то ввод допустимо

выполнять в том же потоке управления;

– требуется совместить вывод на

устройство с вычислениями, нужными для

получения выходных данных. Это делается с

помощью пассивной задачи интерфейса с

устройством вывода, которая вызывается по

запросу, обычно путем посылки ей

сообщения.

Пассивные задачи интерфейса с

устройствами обычно применяются для ра-

боты с устройствами вывода, а не ввода,

поскольку совмещение вывода с вычис-

лениями требуется чаще (см. следующий

пример). Как правило, для совмещения ввода

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

задачи ввода.

53. Задачи-мониторы ресурсов.

Задача-монитор ресурса – это частный

случай пассивной задачи ввода/вывода,

рассмотренной выше. С устройством

ввода/вывода, которое получает запросы из

разных источников, должна быть

ассоциирована задача-монитор для коорди-

нации запросов, даже если устройство

является пассивным. Ее цель – упорядочить

запросы, чтобы гарантировать целостность

данных и избежать их искажения или потери.

54. Критерии выделения внутренних задач

критерии выделения внутренних задач

помогут выявить внутренние задачи, не

связанные с вводом/выводом.

Периодические задачи. Во многих

параллельных системах и системах

реального времени встречаются работы,

которые надо выполнять периодически,

например вычисление пройденного машиной

расстояния или ее текущей скорости. Обычно

для этой цели используются периодические

задачи. Периодом задачи называется

промежуток времени между

последовательными активизациями.

Асинхронные задачи. Во многих

параллельных системах и системах

реального времени встречаются работы,

выполняемые по требованию. Обычно для

них применяются асинхронные задачи. Если

асинхронные задачи ввода/вывода

активизируются прерываниями, то

асинхронные внутренние задачи (их еще

называют апериодическими) активизируются

по требованию, когда приходит внутреннее

сообщение или событие.

Управляющие задачи. В аналитической

модели зависящий от состояния

управляющий объект исполняет диаграмму

состояний. Так как используется

ограниченная форма диаграммы состояний, в

которой параллелизм внутри объекта не

допускается, то ее выполнение оказывается

строго последовательным. Поэтому

последовательно исполняемая задача может

осуществлять управляющую деятельность.

Задача, реализующая последовательную

диаграмму состояний (обычно изображаемая

в виде таблицы переходов состояний),

называется управляющей.

Задачи интерфейса пользователя.

Пользователь, как правило, выполняет

операции последовательно. Поскольку его

взаимодействие с системой носит

последовательный характер, оно реализуется

в виде задачи интерфейса пользователя.

Быстродействие такой задачи часто

ограничено скоростью работы человека. Как и

следовало ожидать, на нее отображается

объект интерфейса пользователя из

аналитической модели.

55. Критерии назначения приоритетов

задачам

Эти критерии помогают выявить высоко-

и низкоприоритетные задачи. Часто

приоритетности задач уделяется внимание

только на поздних стадиях цикла разработки.

Критической по времени называется задача,

которая обязана завершиться к точно

установленному сроку. Такая задача должна

выполняться с высоким приоритетом.

Высокоприоритетные критические по времени

задачи необходимы в большинстве

приложений реального времени.

Некритическая по времени расчетная

задача требует значительных ресурсов

процессора, но может выполняться с низким

приоритетом. Идея о низкоприоритетных

задачах со сложными вычислениями, которые

способны действовать в фоновом режиме и

вытесняться высокоприоритетными

задачами, появилась еще в ранних системах

мультипрограммирования и обычно

поддерживается современными ОС.

56. Критерии группировки задач

Критерии группировки задач, или

критерии слияния задач (task cohesion

criteria), помогают установить, какие из задач,

выявленных на первой стадии процесса

разбиения на задачи, удобно объединить для

уменьшения общего числа задач.

Задачи, определенные на первой стадии

(с помощью критериев выделения задач

ввода/вывода, внутренних задач и критериев

назначения приоритетов), называются

задачами-кандидатами. Критерии груп-

пировки предлагают средства для анализа

природы параллелизма в задачах-кан-

дидатах, что дает возможность решить,

следует ли объединять кандидатов в одну

физическую задачу и как именно. Так, если

две задачи-кандидата должны исполняться

строго последовательно, объединение их в

одну физическую задачу обычно упрощает

проект.

57. Темпоральная группировка.

Некоторые задачи-кандидаты могут

активизироваться одним и тем же событием,

например событием таймера. При каждой

активизации задача выполняет некоторую

деятельность. Если между

последовательными задачами-кандидатами

нет никакой зависимости, то есть порядок

выполнения не имеет значения, их можно

объединить в одну задачу, применив

критерий темпоральной группировки. Когда

такая задача активизируется, по очереди

выполняются все сгруппированные

деятельности. Поскольку никакой

зависимости между ними не существует,

проектировщик вправе выбрать любой

порядок выполнения.

Темпоральная группировка обычно

применяется к кандидатам, которые акти-

визируются периодически. Например, удобно

объединить те задачи-кандидаты, которые

активизируются одним и тем же

периодическим событием с одной и той же

частотой. В темпоральную группу

рекомендуется объединять взаимосвязанные

задачи. Группировать периодические задачи,

которые функционально никак не связаны с

точки зрения проектирования нежелательно,

хотя иногда это допустимо в целях

оптимизации, если накладные расходы на

организацию многозадачности становятся

слишком высокими.

58. Последовательная группировка.

Бывает так, что некоторые задачи

приложения необходимо выполнять строго

последовательно. Первая в цепи таких задач

активизируется асинхронным или пе-

риодическим событием, а все остальные

исполняются после нее одна за другой. Такие

задачи можно объединить, применив

критерий последовательной группировки.

59. Группировка по управлению.

Управляющий объект, который

исполняет последовательную диаграмму со-

стояний, отображается на управляющую

задачу. В некоторых случаях эту задачу

можно объединить с другими объектами,

которые выполняют действия, срабаты-

вающие при переходе или начинающиеся в

момент перехода деятельности. Такой вид

группировки называется группировкой по

управлению.

В аналитической модели зависящий от

состояния управляющий объект опре-

деляется с помощью последовательной

диаграммы состояния. Такому объекту

следует сопоставить отдельную

управляющую задачу, поскольку выполнение

диаграммы состояния по определению строго

последовательно. Но эта задача может

выполнять в своем потоке управления другие

зависящие от состояния действия или

деятельности. Рассмотрим подобные случаи:

– зависящие от состояния действия,

запускаемые управляющим объектом в

момент перехода состояний.

– зависящие от состояния деятельности,

которые начинаются или заканчиваются

управляющим объектом в результате

перехода состояний.

– зависящие от состояния деятельности,

которые запускаются управляющим объектом

в результате перехода состояний и

исполняются, пока объект находится в

данном состоянии.

60. Группировка по взаимному

исключению.

Группировка по взаимному исключению

имеет место, когда есть группа задач, из

которых по условиям приложения в любой

момент времени может исполняться только

одна.

61. Пересмотр проекта путем инверсии

задач

Идея инверсии задач впервые была

сформулирована в методе структурного

программирования Джексона и в системе

разработки Джексона. Такая инверсия

способствует уменьшению числа задач в

системе. В предельном случае параллельное

решение можно вообще свести к

последовательному.

Критерии инверсии задач применяются

для объединения задач с целью сокращения

накладных расходов на организацию

многозадачности. На начальной стадии их

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

накладных расходов очевидна. Если же такая

опасность осознана позже, то к этому вопросу

допустимо вернуться на стадии пересмотра

проекта, в частности если анализ

производительности проекта показал, что

затраты на многозадачность чрезмерно

высоки.

Существует три вида инверсии задач:

инверсия нескольких экземпляров задачи,

инверсия последовательных задач и

темпоральная инверсия.

С помощью инверсии нескольких

экземпляров задачи все однотипные задачи

заменяются одной, выполняющей те же

функции. Инверсия последовательных задач

применяется главным образом тогда, когда

между двумя или более задачами

осуществляется сильно связанный обмен

сообщениями. При темпоральной инверсии,

которая напоминает слабые формы темпо-

ральной группировки, две или более

периодические задач – внутренние,

ввода/вывода или входящие в темпоральную

группу – объединяются.

62. Разработка архитектуры задач

Критерии разбиения на задачи можно

применять к аналитической модели

следующим образом. В каждом случае нужно

сначала решить, будет ли объект из

аналитической модели отображаться на

активный или пассивный объект проектной

модели:

– задачи интерфейса с устройством.

Начните с объектов интерфейса устройств,

взаимодействующих с внешним миром.

– управляющие задачи. Рассмотрите все

зависящие от состояния управляющие

объекты. Отобразите их на управляющие

задачи.

– периодические задачи.

Проанализируйте внутренние периодические

деятельности, которые оформляются как

периодические задачи. Выясните, есть ли

среди них такие, которые запускаются одним

и тем же событием. В этом случае их можно

связать в одну задачу, применив критерий

темпоральной группировки. Возможно,

удастся также задействовать критерий

последовательной группировки для

объединения ряда других задач;

– другие внутренние задачи. Для каждой

внутренней задачи, активизируемой

внутренним событием, проверьте, нет ли

среди соседних с ней задач на диаграмме

параллельной кооперации таких, которые

можно объединить на основе различных

критериев группировки: последовательной,

темпоральной или по взаимному исключению.

Начальная диаграмма параллельной

кооперации. После разбиения системы на

параллельные задачи рисуется начальная

диаграмма параллельной кооперации, на

которой представлены все задачи. Интерфей-

сы задач на ней все еще показываются в виде

простых сообщений, как на диаграммах

кооперации из аналитической модели.

63. Коммуникации между задачами и

синхронизация

Следующий шаг после разбиения

системы на параллельные задачи – опреде-

ление интерфейсов задач. Теперь

необходимо представить интерфейсы в

форме обмена сообщениями, синхронизации

по событиям или доступа к скрывающим

информацию объектам. . В случае слабо

связанного обмена сообщениями,

называемого также асинхронным обменом,

производитель посылает сообщение

потребителю и продолжает работать, не

дожидаясь ответа. Поскольку производитель

и потребитель функционируют с разной

скоростью, то между ними может

существовать FIFO-очередь. Если в момент,

когда потребитель запрашивает сообщение,

его не оказывается, потребитель

приостанавливается. В ситуации сильно

связанного (синхронного) обмена

сообщениями с ответом производитель

посылает потребителю сообщение и ждет

ответа. При поступлении сообщения

потребитель принимает его, обрабатывает,

генерирует ответ и отправляет его назад.

После этого производитель и потребитель

продолжают функционировать. Если

сообщений нет, потребитель

приостанавливается.

В случае сильно связанного обмена

сообщениями без ответа производитель

посылает потребителю сообщение и ждет,

пока оно дойдет до адресата. Потребитель

принимает поступившее сообщение,

освобождая тем самым производителя.

После этого производитель и потребитель

продолжают работать. Если сообщений нет,

потребитель приостанавливается.

Синхронизация по событию. Возможны

три вида такой синхронизации: по внешнему

событию, по событию таймера и по

внутреннему событию. Внешнее событие

поступает из внешнего источника, как

правило, в виде прерывания от устройства

ввода/вывода. Внутреннее событие

обеспечивает внутреннюю синхронизацию

между двумя задачами. Событие таймера

предназначено для периодической

активизации задачи. События изображаются

в UML с помощью нотации асинхронных

сообщений.

Задачи могут обмениваться данными

также с помощью пассивного скрывающего

информацию объекта.

После определения интерфейсов задач

начальная диаграмма кооперации пе-

ресматривается с целью изображения

различных видов интерфейсов.

64. Спецификация поведения задачи

Спецификация поведения задачи (СПЗ)

описывает ее интерфейс, структуру, вре-

менные характеристики, относительный

приоритет, логику упорядочения событий и

обнаруживаемые ошибки. Интерфейс задачи

– это способ ее взаимодействия с другими

задачами. Структура говорит о том, как

данная задача появилась (посредством

какого критерия разбиения). Временные

характеристики – это частота активизации и

ожидаемое время выполнения. Полученная

информация используется для планирования

в реальном времени.

СПЗ прилагается к описанию

архитектуры задач. В процессе разбиения на

задачи в СПЗ заносится информация о

входных и выходных данных задачи. Часть

СПЗ составляется позже, на этапе детального

проектирования программы. Речь идет о

логике упорядочения событий – описании

того, каким образом задача отвечает на

входные события.

65. Проектирование классов

На этом этапе проектируются

скрывающие информацию классы, из которых

создаются экземпляры пассивных объектов.

Первоначально классы определяются на

этапе построения аналитической модели в

ходе разбиения системы на объекты и

классы. Класс применяет сокрытие

информации для решения различных

вопросов, связанных со статической

структурой, например сокрытия информации

об устройстве или абстрагирования данных.

Операции класса можно вывести как из

статической, так и из динамической модели.

Хотя статическая модель предназначена для

отражения операций классов, их проще

выявить посредством анализа динамической

модели – прежде всего, диаграммы

кооперации или последовательности. Ниже

мы покажем, как операции класса выводятся

из модели кооперации, из описания конечного

автомата и из статической модели, но

основное внимание уделим модели

кооперации.

66. Проектирование классов, скрывающих

информацию

Скрывающие информацию классы,

проектируемые на этом этапе, подразде-

ляются на категории в соответствии со

стереотипом. Они документируются с по-

мощью спецификаций интерфейсов.

. Кроме них существуют классы,

зависящие от области решения; они

проектируются позже по мере необходимости:

– сущностные классы, представленные в

аналитической модели, служат для

инкапсуляции данных. На диаграммах

классов они помечаются стереотипом

«сущность». Сущностные объекты –

экземпляры сущностных классов - обычно

хранят в себе информацию и существуют в

течение длительного времени.

– интерфейсные классы, реализующие

интерфейс с внешней средой, можно

разделить на следующие группы:

классы интерфейса устройства,

взаимодействующие с устройствами вво-

да/вывода;

классы интерфейса пользователя,

осуществляющие человеко-машинный

интерфейс;

классы интерфейса системы,

общающиеся с внешней системой или под-

системой;

– управляющие классы,

координирующие совместную работу

нескольких объектов, которые участвуют в

прецеденте. Среди них можно выделить

классы координации, классы, зависящие от

состояния, и классы таймера.

– классы прикладной логики,

инкапсулирующие особенности логики и алго-

ритмов приложения, подразделяются на

классы бизнес-логики и классы алгоритмов;

– внутренние программные классы,

скрывающие те решения проектировщиков,

которые могут впоследствии измениться.

67. Проектирование операций классов

Опишем, как выявляются операции,

предоставляемые классами. Хотя для

отражения операций классов предназначена

статическая модель, их проще выявить на

основе анализа динамической модели,

прежде всего из диаграммы кооперации. Это

обусловлено тем, что в динамической модели

отражен обмен сообщениями между

объектами, а следовательно, и операции

объекта-получателя. Передача сообщений

между пассивными объектами – не что иное,

как вызов операции одного объекта из

операции другого объекта.

Проектирование операций классов на

основе модели взаимодействия. Операции

классов определяются путем рассмотрения

того, как объект данного класса

взаимодействует с другими объектами,

поскольку взаимодействие двух объектов

состоит в том, что один из них вызывает

операцию другого. Рассматривая два

взаимодействующих объекта, необходимо

понять, чьи операции вызываются.

Следовательно, сообщению ставится в

соответствие вызов операции. Имя

сообщения отображается на имя операции, а

параметры сообщения – на параметры

операции.

Проектирование операций классов на

основе конечного автомата. . Операции

классов можно также вывести из диаграммы

состояний. На ней представлены действия и

деятельности, инициируемые в результате

перехода состояний. Действия, как правило,

отображаются на операции класса. На

диаграммах состояний показаны все

зависящие от состояния действия и

деятельности. Если действия выполняются

пассивными классами, то они выводятся из

диаграммы состояний.

Проектировать операции классов на

основе диаграмм классов из статической

модели тоже можно, особенно для

сущностных классов. Стандартными

являются операции создать, читать,

обновить, удалить.

68. Классы абстрагирования данных

Каждый сущностный класс из

аналитической модели, который инкапсулиру-

ет данные, проектируется как класс

абстрагирования данных. Сущностный класс

хранит данные и предоставляет операции для

доступа к ним – операции чтения и записи.

Класс абстрагирования данных используется

для инкапсуляции структуры данных, то есть

сокрытия деталей ее внутреннего

представления. Операции проектируются как

процедуры иди функции доступа, внутреннее

устройство которых также скрыто.

Информация об атрибутах класса

абстрагирования данных должна уже при-

сутствовать в статической модели

предметной области. Операции такого класса

определяются путем рассмотрения тех

сервисов, которые нужны клиентским

объектам для опосредованного доступа к

данным. Это можно сделать,

проанализировав способы использования

объекта абстрагирования данных в модели

кооперации.

69. Классы интерфейса устройства

Одной из важных целей при разработке

программной системы является сокрытие от

пользователей информации о модификациях

реальных устройств ввода/вывода. Типичный

пример такого изменения – это замена одного

устройства другим с той же

функциональностью, но иным аппаратным

интерфейсом. Разумеется, крайне

нежелательно, чтобы подобное изменение

затронуло всех пользователей. Решается

проблема посредством классов интерфейса

устройства, которые предоставляют

виртуальный интерфейс, скрывающий детали

общения с реальным устройством.

С помощью класса интерфейса

устройства концепция сокрытия информации

применяется для инкапсуляции проектного

решения о том, как осуществляется

интерфейс с конкретным устройством

ввода/вывода. С этой целью разрабатыва-

ется класс виртуального интерфейса, в

котором скрываются все детали реального

интерфейса.

Пользователи могут обратиться к

устройству только с помощью виртуального

интерфейса, состоящего из набора операций.

В случае замены устройства и модификации

реального интерфейса пользователи

виртуального интерфейса ничего не узнают,

поскольку спецификация операций остается

прежней. Надо лишь изменить реализацию

этих операций. Таким образом, пользователи

класса изолированы от модификаций

реальной аппаратуры.

70. Классы, зависящие от состояния

Класс, зависящий от состояния,

инкапсулирует информацию, которая пред-

ставлена на диаграмме состояний. На этапе

проектирования классов диаграмма

состояний, исполняемая зависящим от

состояния объектом, отображается на таб-

лицу переходов состояний. Таким образом,

зависящий от состояния класс скрывает

устройство этой таблицы и поддерживает

текущее состояния объекта.

Зависящий от состояния класс

предоставляет операции для доступа к табли-

це переходов состояний и для ее изменения.

В частности, проектируются операции для

обработки входных событий, вызывающих

переходы состояний. Например, можно

задать отдельную операцию для каждого

такого события. Это означает, что зависящий

от состояния класс проектируется специально

для конкретной диаграммы состояний.

71. Классы, скрывающие алгоритмы

Такие классы скрывают алгоритмы,

применяемые в предметной области; они

типичны в системах реального времени, а

также в научных и инженерных приложениях.

Как правило, такой класс скрывает не только

алгоритм, но и локальные данные,

необходимые для его работы.

72. Классы интерфейса пользователя

Класс интерфейса пользователя

скрывает от других классов детали человеко-

машинного интерфейса. В зависимости от

приложения интерфейс пользователя может

быть очень простым (например, в виде

командной строки) или весьма сложным

(графический интерфейс пользователя –

ГИП). Чтобы реализовать интерфейс

командной строки, достаточно одного класса,

а для графического интерфейса требуется,

как правило, несколько. Низкоуровневые

классы интерфейса пользователя – это

элементы управления, находящиеся в

библиотеках компонентов: окна, меню, кнопки

и диалоги. Высокоуровневые классы

пользовательского интерфейса часто

составляются из таких классов.

В аналитической модели акцент

делается на идентификации составных клас-

сов пользовательского интерфейса и сборе

информации о том, какие данные

пользователь должен вводить, а какие ему

надо показать. На этой же стадии можно

проектировать выводимые формы.

73. Классы бизнес-логики

Класс бизнес-логики определяет логику

принятия решения при обработке запроса

клиента, специфичную для данного

приложения. Он предназначен для ин-

капсуляции бизнес-правил, которые способны

изменяться независимо друг от друга.

Обычно во время выполнения объект бизнес-

логики обращается к различным сущностным

объектам.

74. Классы-обертки базы данных

В аналитической модели представлены

сущностные классы, которые инкапсулируют

данные. В ходе проектирования нужно

решить, должна ли информация храниться в

самом сущностном классе или же в базе

данных. В первом случае применяются

классы абстрагирования данных, которые

инкапсулируют структуры данных, а во

втором – классы-обертки базы данных,

скрывающие детали реализации доступа к

базе.

На сегодняшний день наиболее широко

распространены реляционные базы данных,

так что класс-обертка предоставляет

объектно-ориентированный интерфейс к

такой базе. При этом необходимо отобразить

сущностные классы из статической модели на

структуры базы данных.

Класс-обертка скрывает детали доступа

к данным, хранящимся в таблицах базы, а

значит, и все операторы языка SQL. Обычно

один класс соотносится с одной таблицей, но

возможны также классы-обертки и для

представлений, то есть соединения двух или

более таблиц.

75. Внутренние программные классы

Внутренние программные классы

скрывают решения разработчика, которые

могут со временем измениться. Обычно они

создаются на поздних стадиях процесса

проектирования. Определить их из

аналитической модели, относящейся к

предметной области, невозможно.

Внутренние программные классы

инкапсулируют различные структуры данных

(стеки, очереди, таблицы данных),

выбранные проектировщиком. Примерами

внутренних классов являются также классы-

разъемы

76. Применение наследования при

проектировании

Наследование полезно при

проектировании двух похожих классов, то

есть таких, у которых много общих черт. На

этапе проектирования архитектуры его нужно

иметь в виду, чтобы впоследствии на этапах

детального проектирования и кодирования

можно было повторно использовать тот же

или слегка видоизмененный код.

Наследование задействуют и с целью

сделать проект более удобным для

сопровождения – такое применение оченъ

упрощает инкрементную модификацию

программы.

Иерархии классов (называемые также

иерархиями обобщения/специализации или

иерархиями наследования) допустимо

разрабатывать сверху вниз, снизу вверх или в

обоих направлениях. При разработке сверху

вниз проектируется класс, который включает

характеристики, общие для всех его

наследников. В ходе специализации этого

класса формируются подклассы со

специфическими особенностями.

У абстрактного класса не может быть

экземпляров, поэтому он используется как

шаблон для создания классов, а не объектов.

Иными словами, он способен выступать

только в роли суперкласса, который

определяет общий интерфейс для всех своих

подклассов. Абстрактная операция – это

операция, которая объявлена, но не

реализована в абстрактном классе.

Абстрактный класс должен иметь хотя бы

одну абстрактную операцию.

В объектно-ориентированном

проектировании полиморфизм используется,

когда в различных классах должна

существовать операция с одним и тем же

именем. Ее спецификация во всех классах

одинакова, но реализация может быть

различной: это дает возможность во время

выполнения использовать вместо одного

объекта другой с тем же интерфейсом.

Динамическое связывание применяется

совместно с полиморфизмом для ас-

социирования запроса с объектом и одной из

его операций во время исполнения. При

статическом связывании (типичный случай в

процедурных языках) ассоциация запроса с

операцией устанавливается во время

компиляции, ее нельзя впоследствии

изменить. При динамическом связывании,

напротив, запрос может сначала выполняться

операцией одного объекта, а потом

операцией другого объекта.

77. Примеры наследования

Примеры суперклассов и подклассов. В

банковской системе класс Счет имеет два

атрибута: номерСчета и баланс.

Пример полиморфизма и динамического

связывания. Рассмотрим теперь создание

объектов этих классов, а также пример

полиморфизма и динамического связывания.

Следует отметить, что объекту типа

Счет можно присвоить объект типа Чековый

Счет или Сберегательный Счет, но обратное

неверно. Дело в том, что каждый Чековый

Счет является Счетом, равно как и каждый

Сберегательный Счет является Счетом,

однако нельзя сказать, будто каждый Счет

является Сберегательным, он может быть и

Чековым. Пример наследования

абстрактному классу.

Рис.9.11. Пример абстрактного

суперкласса и подклассов

78. Спецификация интерфейса класса

В спецификации интерфейса класса

определяется интерфейс скрывающего

информацию класса, в том числе его

операции. Спецификация должна включать:

– описание информации, скрываемой

классом, например инкапсулированную

структуру данных (если речь идет о классе

абстрагирования данных) или интерфейс

устройства;

– критерий, на основании которого был

выделен данный класс;

– предположения, сделанные при

специфицировании класса: могут разные за-

дачи получать одновременный доступ к

операциям объекта этого класса или доступ

должен быть строго последовательным;

– предположительные модификации,

побуждающие проектировать с учетом

возможных изменений;

– суперкласс (если есть);

– унаследованные операции (если есть);

– операции класса. Для каждой операции

необходимо определить:

выполняемую функцию;

предусловие (условие, которое должно

выполняться перед вызовом операции);

постусловие (условие, которое должно

выполняться после вызова операции);

инвариант (условие, которое должно

выполняться всегда);

входные параметры;

выходные параметры;

вызываемые операции других классов.

Спецификацию интерфейса класса

можно представить в описательной или

табличной форме.

79. Детальное проектирование ПО

После разбиения системы на задачи и

проектирования скрывающих информацию

классов следует приступать к детальному

проектированию программы. На этом этапе

разрабатывается внутреннее устройство

составных задач, содержащих вложенные

объекты, подробно рассматриваются вопросы

синхронизации, создаются классы-разъемы,

инкапсулирующие детали межзадачных

коммуникаций, и определяется внутренняя

логика упорядочения событий для каждой

задачи. Детальный проект подсистемы

изображается на детальных диаграммах

параллельной кооперации, которые

конкретизируют диаграммы, разработанные

на этапе разбиения на задачи. Здесь

изображается внутреннее строение

сгруппированных задач и объектов-разъемов.

80. Проектирование составных задач

Рассмотрим детальное проектирование

составных задач, содержащих вложенные

объекты. К ним относятся задачи,

выявленные путем применения критериев

группировки и инверсии. Обычно такие задачи

проектируются в виде составных активных

классов, включающих вложенные пассивные

объекты.

Отношения между задачами и классами

выстраиваются следующим образом.

Активный объект – задача – запускается

событием: внешним, внутренним или

таймера. Затем он вызывает определенную

операцию пассивного объекта. Пассивный

объект бывает вложенным в задачу или

внешним по отношению к ней. Эти два случая

рассматриваются отдельно.

Класс, операции которого вызываются

исключительно указанной задачей, может

вкладываться в нее. Если же операции класса

вызываются несколькими задачами, то класс

должен оставаться внешним по отношению к

каждой из них. В случае, когда обращения к

классу осуществляются из разных задач,

операции класса должны обеспечивать

синхронизацию доступа к инкапсулированным

данным.

Иногда полезно разделить обязанности

между задачей и вложенными в нее

классами. Управление, упорядочение

событий и коммуникации поручаются задаче,

а все структурные детали оставляются на

усмотрение скрывающего информацию

класса.

Рассмотрим ввод/вывод с опросом с

точки зрения разбиения на задачи и классы.

Задача выделяется при помощи критерия

периодической (если устройство одно) или

темпоральной (если устройств несколько)

группировки. Каждое пассивное устройство

ввода/вывода инкапсулируется в класс

интерфейса устройства. Необходимо

определить операции, предоставляемые

таким классом, и поместить класс внутрь

задачи.

Рассмотрим теперь динамическое

поведение. Задача активизируется событием

таймера. Затем она вызывает операции

каждого из объектов интерфейса, чтобы

получить текущее состояние устройства.

Рассмотрим группировку задач по

управлению и объекты, скрывающие

информацию. Управляющая задача

активизируется асинхронно. Она вызывает

операции одного или нескольких объектов.

81. Синхронизация доступа к классам

Если к классу может обращаться

несколько задач, то его операции должны

обеспечивать синхронизацию доступа к

инкапсулируемым данным. Ниже описы-

ваются соответствующие механизмы:

алгоритм взаимного исключения и алгоритм

нескольких читателей и писателей.

Отделив вопрос о том, что делает класс

(спецификация операций), от того, как это

делается (проект класса), мы можем

изолировать пользователей от модификаций

внутреннего устройства класса. Допустимо

следующее:

– трансформировать внутренние

структуры данных, например применить

связанный список вместо массива;

– заменить внутренний механизм

синхронизации доступа к данным, в частности

использовать алгоритм читателей и

писателей вместо взаимного исключения.

Описанные изменения влияют только на

внутреннее устройство класса: на

внутренние структуры данных и внутренние

операции, которые имеют доступ к этим

структурам.

82. Пример синхронизации доступа к

классу

В качестве примера рассмотрим класс

абстрагирования данных Хранилище

Показаний Аналоговых Датчиков. При

проектировании этого класса нужно принять

решение о том, будет ли информация

храниться в массиве или в связанном списке.

Другое решение касается синхронизации:

может ли к объекту такого класса

осуществляться параллельный доступ и, если

да, следует использовать алгоритм взаимного

исключения или алгоритм читателей и

писателей. Оба решения относятся только к

проектированию класса, не затрагивая его

пользователей.

Отделив вопрос о том, что делает класс

(спецификация операций), от того, как это

делается (проект класса), мы можем

изолировать пользователей от модификаций

внутреннего устройства класса. Допустимо

следующее:

– трансформировать внутренние

структуры данных, например применить

связанный список вместо массива;

– заменить внутренний механизм

синхронизации доступа к данным, в частности

использовать алгоритм читателей и

писателей вместо взаимного исключения.

Описанные изменения влияют только на

внутреннее устройство класса: на

внутренние структуры данных и внутренние

операции, которые имеют доступ к этим

структурам.

83. Синхронизация методом взаимного

исключения.

Сначала рассмотрим решение,

основанное на взаимном исключении. В таком

случае используется предоставляемый

операционной системой двоичный семафор, у

которого есть операции acquire (запросить) и

release (освободить). Чтобы гарантировать

взаимное исключение, каждая задача должна

вызвать операцию acquire семафора

readWriteSemaphore (изначально он

установлен в единицу) перед тем, как

пытаться получить доступ к хранилищу.

Закончив работу с хранилищем, задача

обращается к операции release. При

выполнении операции обновить надо не

только записать в хранилище новое значение

датчика, но и проверить условие тревоги.

84. Синхронизация нескольких читателей и

писателей

Применение указанного метода

позволяет нескольким читателям одновре-

менно обращаться к хранилищу, но любой

писатель получает монопольный доступ. Для

этого применяются два двоичных семафора:

readerSemaphore и readWriteSemaphore,

инициализированных значением 1. Кроме

того, хранится текущее число Читателей,

первоначально равное нулю. Семафор

readerSemaphore используется читателями,

чтобы гарантировать взаимно исключающее

обновление счетчика читателей. Семафор

readWriteSemaphore задействован

писателями для обеспечения взаимно

исключающего доступа к хранилищу. Но к

данному семафору обращаются также и

читатели. Он захватывается первым

читателем перед началом чтения из

хранилища и освобождается последним

читателем, закончившим чтение.

85. Синхронизация нескольких читателей и

писателей с помощью монитора.

речь пойдет о применении мониторов

для решения проблемы нескольких читателей

и писателей.

к задаче посредством алгоритма

читателей и писателей мониторы напрямую

применяться не могут, так как операция

читатьАналоговый Датчик должна

одновременно выполняться несколькими

читателями. Поэтому мы поступим иначе:

инкапсулируем аспекты алгоритма читателей

и писателей, касающиеся синхронизации, в

монитор и перепроектируем класс Хранилище

Показаний Аналоговых Датчиков.

86. Синхронизация нескольких читателей и

писателей без ущемления писателей

. Если от читателей постоянно

поступают запросы на чтение, писателю в

течение неопределенно долгого времени

может быть отказано в доступе к хранилищу.

Этот феномен называется ущемлением

писателя (writer starvation). Ниже показано

решение проблемы путем введения

дополнительного семафора writer Waiting.

Операция startWrite теперь должна захватить

семафор writerWaiting до захвата семафора

readWrite Semaphore. Операция startRead

захватывает (и освобождает) семафор

writerWaiting перед тем, как захватить reader

Semaphore.

Поясним, для чего нужны такие

изменения. Предположим, что несколько чи-

тателей заняты чтением, а писатель в этот

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

успешно захватывает семафор writerWaiting,

но дальше вынужден ждать, пока читатели

освободят семафор readWriteSemaphore.

Если приходит новый читатель, то он

вызывает startRead и приостанавливается,

ожидая освобождения семафора

writerWaiting. Тем временем уже имеющиеся

читатели заканчивают свои операции, и

последний освобождает семафор

readWriteSemaphore, который тут же

переходит в распоряжение ожидающего

писателя, а тот освобождает семафор

writerWaiting, позволяя занять его читателю

или писателю.

87. Проектирование разъемов для

межзадачных Коммуникаций

Классы-разъемы инкапсулируют детали

межзадачных коммуникаций, например

сильно и слабо связанный обмен

сообщениями. Сервисы для межзадачных

коммуникаций и синхронизации может

предоставлять многозадачное ядро. По-

добные механизмы есть также в некоторых

языках параллельного программирования, в

частности Ada или Java. Но ни один из этих

языков не поддерживает слабо связанный

обмен сообщениями. Чтобы реализовать

указанную возможность, необходимо

спроектировать скрывающий информацию

класс MessageQueue, инкапсулирующий

очередь сообщений и предоставляющий

операции для доступа к ней. Классы такого

вида называются разъемами.

Каждый разъем представляет собой

монитор, одновременно обеспечивающий

синхронизацию и скрывающий информацию о

том, как это делается. В разъемах

применяется синхронизация по условию.

Такие мониторы могут использоваться как в

однопроцессорной так и в многопроцессорной

системе с разделяемой памятью.

88. Проектирование разъема,

реализующего очередь сообщений.

Разъем, реализующий очередь

сообщений, используется для инкапсуляции

механизма слабо связанного обмена

сообщениями. Это монитор,

инкапсулирующий очередь, которая обычно

существует в виде связанного списка. Разъем

предоставляет синхронизированные

операции send для отправки сообщения

(вызывается задачей-производителем) и

receive для получения сообщения

(вызывается задачей-получателем)

Производитель приостанавливается,

если очередь заполнена (messageCount =

maxCount) и возобновляет работу, когда

освобождается место для размещения нового

сообщения. Поместив сообщение в очередь,

производитель продолжает работать и в

состоянии посылать новые сообщения.

Потребитель приостанавливается, когда

очередь пуста (messageCount = 0) и ак-

тивизируется, как только в очередь поступит

сообщение. Потребитель не при-

останавливается, если в очереди есть

сообщения. Предполагается, что может быть

несколько производителей и один

потребитель.

89. Проектирование разъема,

реализующего буфер сообщений

Разъем, реализующий буфер

сообщений, используется для инкапсуляции

механизма сильно связанного обмена

сообщениями без ответа. Это монитор, инкап-

сулирующий буфер на одно сообщение.

Разъем предоставляет синхронизированные

операции для отправки и получения

сообщений. Производитель вызывает

операцию send, а потребитель – операцию

receive. Производитель приостанавливается,

если буфер заполнен. Поместив сообщение в

буфер, производитель ждет, пока

потребитель примет его. Потребитель

приостанавливается, когда буфер пуст.

Предполагается, что может быть несколько

производителей и один потребитель.

90. Проектирование разъема,

реализующего буфер сообщений с

ответом

. Разъем, реализующий буфер

сообщений с ответом, используется для

инкапсуляции механизма сильно связанного

обмена сообщениями с ответом. Это

монитор, инкапсулирующий буфер на одно

сообщение и буфер на один ответ. Разъем

предоставляет синхронизированные

операции для отправки и получения

сообщений, а также для отправки ответа.

Производитель вызывает операцию send для

пересылки сообщения, а потребитель –

операцию receive для приема сообщения и

операцию reply для отправки ответа.

Поместив сообщение в буфер, производитель

ждет ответа от потребителя. Потребитель

приостанавливается, когда буфер пуст.

Предполагается, что может быть несколько

производителей и один потребитель.

91. Проектирование кооперативных задач

с использованием разъемов.

Теперь рассмотрим проектирование

группы кооперативных задач, общающихся

между собой с помощью объектов-разъемов.

Для иллюстрации воспользуемся примером

из подсистемы Банкомат. Есть два разъема –

очереди сообщений и один разъем – буфер

сообщений.

Объект Очередь Сообщений Управления

Банкоматом инкапсулирует очередь входных

сообщений задачи Контроллер Банкомата,

для которой есть несколько производителей.

Объект Очередь Сообщений Приглашений

инкапсулирует очередь сообщений,

посылаемых задачей Контроллер Банкомата

задаче Интерфейс Клиента. И в том, и в

другом случае производитель вызывает

операцию send объекта-разъема, а

потребитель – операцию receive того же

объекта. Имеется также разъем буфер

Сообщений Устройства Считывания, который

инкапсулирует синхронный обмен без ответа

между задачами Контроллер Банкомата и

Интерфейс Устройства Считывания Карточек.

Наконец, есть объект заместитель

Банковского Сервера. Он скрывает детали

коммуникации с удаленным Банковским

Сервером, применяя синхронный обмен

сообщениями без ответа. Например, в языке

Java этот заместитель воспользовался бы

механизмом вызова удаленных методов

(RMI), описанным ранее.

92. Логика упорядочения событий

На этапе детального проектирования ПО

заполняется раздел «Логика упорядочения

событий» в спецификации поведения задач.

Логика упорядочения событий описывается

неформально на псевдокоде или на

естественном языке и иногда дополняется

диаграммой. Например, для управляющей

задачи может быть построена диаграмма

перехода состояний.

В случае составной задачи с

несколькими вложенными объектами входные

сообщения принимает вложенный объект-

координатор, который затем вызывает

операции прочих объектов. Следовательно,

он реализует логику упорядочения событий.

93. Анализ производительности проекта

параллельной системы

Анализ производительности проекта

особенно важен для систем реального вре-

мени. Если такая система не справляется со

своими задачами в течение отведенного

интервала, последствия могут быть

катастрофическими.

Количественный анализ проекта

системы реального времени позволяет на

ранних этапах выявить потенциальные

проблемы с производительностью. Анализу

подвергается проект ПО, концептуально

исполняемый на данной аппаратной

конфигурации с рассчитанной внешней

рабочей нагрузкой. Обнаружив вероятные

проблемы, легко рассмотреть

альтернативные подходы к проектированию

или иную конфигурацию аппаратуры.

94. Теория планирования в реальном

времени. Планирование периодических

задач

В теории планирования в реальном

времени рассматриваются вопросы приори-

тетного планирования параллельных задач с

жесткими временными ограничениями. В

частности, она позволяет предсказать, будет

ли группа задач, для каждой из которых

потребление ресурсов ЦП известно,

удовлетворять этим ограничениям. В теории

предполагается использование алгоритма

приоритетного планирования с вытеснением.

По мере своего развития теория

планирования в реальном времени применя-

лась к все более сложным задачам, в числе

которых планирование независимых

периодических задач, планирование в

ситуации, когда есть и периодические, и

апериодические (асинхронные) задачи, а

также планирование задач, требующих

синхронизации.

Планирование периодических задач.

Изначально алгоритмы планирования в

реальном времени разрабатывались для

независимых периодических задач, то есть

таких периодических задач, которые не

взаимодействуют друг с другом и,

следовательно, не нуждаются в синхро-

низации. Периодическая задача

характеризуется периодом Т (частота

запуска) и временем выполнения С (время

ЦП, необходимое для завершения одного

запуска). Коэффициент использования ЦП

для нее равен U = С/Т. Задача называется

планируемой (schedulable), если она

удовлетворяет всем временным

ограничениям, то есть ее исполнение

завершается до истечения периода. Группа

задач именуется планируемой, когда

планируемой является каждая входящая в

нее задача.

95. Теорема о верхней границе

коэффициента использования ЦП.

Пользуясь теорией планирования,

можно показать, что группа независимых пе-

риодических задач всегда удовлетворяет

временным ограничениям при условии, что

сумма отношений С/Т по всем задачам

меньше некоторого граничного значения.

Теорема о верхней границе

коэффициента использования ЦП гласит:

Множество из п независимых

периодических задач, планируемых согласно

алгоритму монотонных частот, всегда

удовлетворяет временным ограничениям,

если

)()12(...

nUn



где С

и Т

– время выполнения и период

задачи t

соответственно.

Верхняя граница U(n) стремится к 69%

(ln 2), когда число задач стремится к

бесконечности. Значения верхней границы

для числа задач от 1 до 9 приведены в

табл.11.1. Это оценка для худшего случая, но,

как показано в работе [22], для случайно

выбранной группы задач вероятная верхняя

граница равна 88%. Если периоды задач

гармоничны (являются кратными друг другу),

то верхняя граница оказывается еще выше.

Обобщенная теорема о верхней границе

коэффициента использования (теорема 4):

}(





















kii

CBC

Здесь U

– верхняя граница

коэффициента использования ЦП за период

для задачи t

. Первый член в полученной

формуле – суммарное использование за счет

вытеснения высокоприоритетными задачами

с периодом меньшим, чем у t

. Второй член

соответствует использованию процессора

задачей t

Третий член учитывает время

блокировки задачи t

в худшем случае, а

четвертый – суммарное время вытеснения

этой задачи более приоритетными, но с

периодами меньшими, чем у t

Достоинство алгоритма монотонных

частот заключается в том, что он сохраняет

устойчивость в условиях краткосрочной

перегрузки.

96. Теорема о времени завершения.

Если для некоторого множества задач

полный коэффициент использования больше,

чем требует теорема о верхней границе, то

можно прибегнуть к помощи теоремы о

времени завершения

Теорема о времени завершения

(теорема 2) гласит:

Если имеется такое множество

независимых периодических задач, в котором

каждая задача успевает завершиться

вовремя в случае, когда все задачи запуска-

ются одновременно, то все задачи смогут

завершиться вовремя при любой комбинации

моментов запуска.

Чтобы убедиться в выполнении условий

теоремы, необходимо проверить момент

завершения первого периода для данной

задачи t

, а также моменты завершения

периодов всех задач с более высоким

приоритетом. Согласно алгоритму

монотонных частот, периоды подобных задач

будут меньше, чем для задачи t

. Эти периоды

называются точками планирования. Задача t.

один раз займет ЦП на время С

в течение

своего периода Т

. Но более приоритетные

задачи будут выполняться чаще и могут по

крайней мере один раз вытеснить t

. Поэтому

нужно учесть также время ЦП, затраченное

на более приоритетные задачи.

Теорема о времени завершения

графически представляется с помощью вре-

менной диаграммы, на которой показана

упорядоченная по времени последова-

тельность выполнения группы задач.

97. Строгая формулировки теоремы о

времени завершения

Теорему о времени завершения можно

строго сформулировать следующим образом:

Множество независимых периодических

задач, планируемых согласно алгоритму

монотонных частот, будет удовлетворять

временным ограничениям при любой

комбинации моментов запуска тогда и только

тогда, когда

min,1,





















Cnii

Rpk ),(

где С

и Т

– время выполнения и период

задачи t

соответственно, а

= {(k,p): l≤k≤i, p=l,...,[T

]}.

В этой формуле t

– это проверяемая

задача, a t

– любая из более приоритетных

задач, влияющих на время выполнения t

. Для

данной пары задач t

и t

каждое значение р

представляет некоторую точку планирования

задачи t

. В каждой точке планирования

необходимо рассмотреть один раз время ЦП

, потраченное на задачу t

, а также время,

израсходованное на более приоритетные

задачи. Это позволит определить, успеет ли t

завершить выполнение к данной точке

планирования.

98. Планирование периодических и

апериодических задач. Планирование с

синхронизацией задач

Теория планирования в реальном

времени распространяется и на синхрони-

зацию задач. Проблема здесь в том, что

задача, входящая в критическую область,

может блокировать другие более

приоритетные задачи, которые хотят войти в

ту же область. Ситуация, когда

низкоприоритетная задача не дает

выполняться высокоприоритетной,

называется инверсией приоритетов. Обычно

это связано с тем, что первая задача

захватывает ресурс, который нужен второй.

Протокол предельного приоритета [24]

позволяет избежать тупиковой ситуации и

гарантирует ограниченную инверсию

приоритетов за счет того, что

высокоприоритетная задача может

блокироваться самое большее одной

низкоприоритетной. Чтобы предотвратить

задержку высокоприоритетных задач

низкоприоритетными на долгое время,

применяется коррекция приоритетов. Когда

низкоприоритетная задача t

оказывается в

критической области, она в состоянии

блокировать высокоприоритетные задачи,

которым нужен тот же ресурс. Если это

происходит, то приоритет t

повышается до

максимального из приоритетов блокируемых

задач. Цель состоит в том, чтобы ускорить

выполнение низкоприоритетной задачи и

сократить время ожидания для

высокоприоритетных.

Предельный приоритет Р двоичного

семафора S – максимум из приоритетов всех

задач, которые могут занять данный

семафор. Таким образом, низкоприоритетная

задача, захватившая S, способна повысить

свой приоритет до Р в зависимости от того,

какие задачи она блокирует.

Еще одна возможная проблема – это

тупиковая ситуация (deadlock), которая

возникает, когда двум задачам нужно

захватить по два ресурса. Если каждая

задача захватит по одному ресурсу, то ни

одна не сможет завершиться, поскольку будет

ждать, пока другая освободит ресурс.

Протокол предельного приоритета справля-

ется и с такой трудностью [24].

Теоремы о планировании методом

монотонных частот необходимо обобщить на

задачу об инверсии приоритетов.

99. Развитие теории планирования в

реальном времени

Теорию планирования в реальном

времени можно применить к множеству

параллельных задач либо на этапе

проектирования, либо уже после реализации

всех задач. Поскольку во время

проектирования для времени ЦП существуют

только приблизительные оценки, нужно быть

осторожнее и при разработке задач

реального времени с жесткими временными

ограничениями полагаться на песси-

мистическую теорему о верхней границе

коэффициента использования. Эта теорема

дает верхнюю границу 0,69 в худшем случае,

хотя теория планирования в реальном

времени часто указывает более высокие

значения. Если верхняя граница в худшем

случае не может быть достигнута, придется

изучить альтернативные решения. С точки

зрения проектировщика-пессимиста, оценка

верхней границы коэффициента выше 0,69

приемлема при условии, что использование

сверх 0,69 целиком обусловлено

низкоприоритетными задачами с мягкими

временными ограничениями или задачами,

которые могут исполняться не в реальном

масштабе времени. Для таких задач

эпизодический пропуск срока выполнения не

столь важен.

100. Планирование в реальном времени и

проектирование. Пример применения

обобщенной теории планирования в

реальном времени

В качестве примера рассмотрим

следующий случай. Есть четыре задачи: две

периодические и две апериодические. Ниже

приведены детальные характеристики задач,

причем время указано в миллисекундах, а

коэффициент использования U

Периодическая задача t

: С

= 20; Т

100; U

= 0,2.

Апериодическая задача t

: С

= 15; Т

150; U

= 0,1.

Управляемая прерываниями задача t

= 4; Т

= 200; U

= 0,02.

Периодическая задача t

: C

= 30; T

300; U

= 0,1.

Кроме того, известно, что задачи t

, t

и t

обращаются к одному и тому же хранилищу

данных, защищенному семафором S.

Задачам назначены приоритеты в

строгом соответствии с алгоритмом моно-

тонных частот, то есть t

имеет наивысший

приоритет, а за ней следуют t

, t

и t

Но,

поскольку для t

время реакции жестко

ограничено, ей присвоен наивысший

приоритет, а уже потом идут t

, t

и t

Сначала рассмотрим управляемую

прерываниями задачу t

. Поскольку у нее

самый высокий приоритет, она получает

процессор по первому требованию. Для

применения обобщенной теоремы о верхней

границе коэффициента использования надо

принять во внимание четыре фактора:

– время вытеснения более

приоритетными задачами с периодами

меньшими, чем Т

. Таких задач нет;

– время выполнения С

задачи t

равно

20. Коэффициент использования U

= 0,2;

– вытеснение более приоритетными

задачами с большими периодами. В эту

категорию попадает задача t

. Коэффициент

использования за счет вытеснения на

периоде Т

равен С

/Т

= 4/100 = 0,04;

– время блокировки задачами с более

низким приоритетом. Потенциально за-

блокировать t

могут задачи t

и t

Коэффициент использования за счет

блокировки на периоде Т

составляет B

/Т

30/100 = 0,3.

Коэффициент использования в худшем

случае равен сумме всех полученных

коэффициентов, то есть 0,04 + 0,2 + 0,3 =

0,54, что меньше верхней границы 0,69.

Следовательно, t

удовлетворяет временным

ограничениям.

Далее таким же образом рассматриваем

остальные задачи

101. Анализ производительности с

помощью анализа последовательности

событий

На этапе определения требований

задается время реакции системы на внешние

события. После разбиения на задачи можно

предпринять первую попытку выделения

временных бюджетов параллельным

задачам. Для выявления задач, которые

необходимо выполнить при обслуживании

данного внешнего события, используется

анализ последовательности событий. Чтобы

показать последовательность событий и

задач, активизируемых приходом внешнего

события, применяется диаграмма

последовательности событий, основанная на

диаграмме параллельной кооперации.

Следует рассмотреть внешнее событие,

определить, какая задача ввода/вывода

активизируется таким событием и какая

ожидается цепочка внутренних событий. Для

этого необходимо знать, какие задачи

активизируются и какие задачи ввода/вывода

генерируют отклик системы на внешнее

событие. Далее нужно оценить время ЦП,

потребляемое каждой задачей, и накладные

расходы, состоящие из затрат на контекстное

переключение, обработку прерывания и

межзадачные коммуникации и

синхронизацию. Надо проанализировать

также другие задачи, выполняемые в тот же

период времени. Суммарное время ЦП,

потребляемое всеми задачами, которые

участвуют в цепочке событий, и всеми

дополнительными задачами, которые

исполнялись в то же время, плюс накладные

расходы – все вместе не должно превысить

заданное время реакции системы. Если вы не

знаете точно времени ЦП, потребляемого

каждой задачей, принимайте оценку для худ-

шего случая.

Для анализа полного коэффициента

использования ЦП необходимо рассчитать

время, потребляемое каждой задачей на

данном интервале. Если существует не-

сколько путей выполнения задачи, то нужно

получить оценку времени для каждого из них.

Затем следует оценить частоту активизации

задач. Для периодических задач это легко.

Для асинхронных задач удобно рассмотреть

среднюю и максимальную частоту

активизации. Умножьте время ЦП для каждой

задачи на ее частоту активизации,

просуммируйте результаты и вычислите

коэффициент использования ЦП.

102. Анализ производительности с

помощью теории планирования в

реальном времени и анализа

последовательности событий

Вместо того чтобы рассматривать за-

дачи по отдельности, необходимо изучить все

задачи, участвующие в некоторой

последовательности событий. Сначала

исполняется задача, активизируемая внеш-

ним событием, которая инициирует цепочку

внутренних событий, а они, в свою очередь,

активизируют другие задачи. Необходимо

убедиться, что все задачи, вошедшие в

цепочку, способны завершить исполнение

вовремя.

Для начала назначьте всем задачам в

цепочке одинаковые приоритеты. С точки

зрения теории планирования в реальном

времени вместо них можно рассмотреть одну

эквивалентную задачу. В качестве периода

эквивалентной задачи устанавливается

время в худшем случае между

последовательными приходами внешнего

события, активизирующего цепочку.

Чтобы определить, удовлетворяет ли

эквивалентная задача временным огра-

ничениям, нужно применить теоремы из

теории планирования в реальном времени – в

частности, рассмотреть вытеснение

высокоприоритетными задачами, блокировку

низкоприоритетными задачами и время

выполнения эквивалентной задачи.

103. Пример анализа производительности

с помощью анализа последовательности

событий .

В качестве примера рассмотрим

подсистему Круиз-Контроль из системы круиз-

контроля и мониторинга. Вначале

проанализируем случай, когда водитель

переводит ручку круиз-контроля в положение

«Разгон», инициируя тем самым

автоматическое ускорение машины. В

требованиях к системе записано, что система

должна отреагировать на это действие в

течение 250 мс. Предположим, что

подсистема Круиз-Контроль находится в

состоянии Начальное. Имеем некоторую

последовательность событий С1 – С9.

Полное время, которое ЦП расходует на

эти четыре задачи (С

), равно сумме времен

выполнения каждой задачи и времени,

необходимого для межзадачных

коммуникаций, плюс затраты на контекстное

переключение:

= С

+ C

+ С

4С

Чтобы определить время реакции

системы, необходимо также принять во вни-

мание другие задачи, которые способны

выполняться, пока система обрабатывает

внешнее событие.

Полное время ЦП не должно превышать

предельное время реакции, указанное в

требованиях к системе. Это полное время

равно

= С

+ С

Прежде чем решать приведенные

уравнения, нужно оценить каждый из вре-

менных параметров.

104. Пример анализа производительности

с применением теории планирования в

реальном времени

Проанализируем худший случай, когда

от ЦП требуется больше всего времени:

машина движется в режиме автоматического

управления с максимальной скоростью

вращения вала. Пусть период j-ой

периодической задачи равен Т

, время ее

выполнения С

, а коэффициент

использования ЦП U

= С

/ Т

. Во время, по-

требляемое каждой периодической задачей,

включены затраты на два контекстных

переключения. В табл.11.3 приведены

характеристики всех периодических задач.

Частотно-монотонные приоритеты

присваиваются задачам так, что более при-

оритетными оказываются задачи с меньшим

периодом. Значит, самый высокий приоритет

будет иметь задача Интерфейс Вала. Задача

Автодатчики активна всегда, а задача

Интерфейс Дросселя – только в режиме

автоматического управления. Задаче

Автодатчики назначен более высокий

приоритет, поскольку от полученной ею

входной информации (например, о нажатии

тормоза) может зависеть воздействие на

дроссель. Самый низкий приоритет у задачи

Таймер Обслуживания, которая имеет

максимальный период. Отметим, что доступ к

разделяемым хранилищам данных включает

одну команду чтения или одну команду

записи. Это настолько мало, что временем

задержки из-за блокировки одной задачи

другой допустимо пренебречь.

105. Анализ производительности по

теории планирования в реальном

времени и анализа последовательности

событий

Эквивалентная апериодическая задача.

Необходимо учесть влияние, которое

оказывает дополнительная нагрузка,

вызванная действиями водителя, на

стационарную нагрузку, обусловленную пе-

риодическими задачами. Из теории

планирования в реальном времени следует,

что апериодическую задачу можно

рассматривать как периодическую с

периодом, равным минимальному интервалу

между событиями. Пусть период

эквивалентной апериодической задачи равен

. Предположим, что Т

– это еще и

максимальное время реакции на действия

водителя. Например, если Т

составляет 250

мс, то система должна отреагировать на

нажатие тормоза или отключение круиз-

контроля в течение 250 мс. Для

эквивалентной периодической задачи

последовательности событий будем считать,

что водитель способен инициировать не

более четырех внешних событий в секунду,

это худший и крайне маловероятный случай.

Тем не менее, если удастся доказать, что

система может справиться и с такой

ситуацией, уверенность в ее

работоспособности многократно возрастет.

Назначение других приоритетов. Сна-

чала рассмотрим допущение о том, что всем

задачам можно назначить частотно-

монотонные приоритеты.

106. Пересмотр проекта

Если первоначальный проект не

отвечает требованиям, предъявляемым к эф-

фективности, то его необходимо

пересмотреть. Для этого применяются

критерии разбиения на задачи и критерии

инверсии задач, в частности более слабые

формы группировки задач (темпоральная

инверсия) и другие виды инверсии: инверсия

нескольких экземпляров задачи и инверсия

последовательных задач.

107. Оценка и измерение параметров

производительности

Прежде чем приступать к анализу

производительности, необходимо оценить

или измерить различные временные

параметры. Это независимые переменные.

Оценки для зависимых переменных дает

теория планирования в реальном времени.

Основное предположение, на котором

базируется теория планирования в реальном

времени, состоит в том, что все задачи

находятся в оперативной памяти, поэтому

время на подкачку страниц не тратится.

Такого рода накладные расходы могли бы

внести дополнительную неопределенность и

задержки, нетерпимые в системах с жесткими

временными ограничениями.

Ниже приведены параметры, которые

нужно оценить для каждой задачи:

– период задачи Т

, то есть частота ее

выполнения. Для периодических задач

период фиксирован. Для апериодических

задач берется худший случай: минимальное

время между последовательными внешними

событиями, которые ее активизируют. Затем

полученная величина экстраполируется на

внутренние задачи, которые принимают

участие в обработке данного события;

– время выполнения С

, то есть

потребляемое задачей время процессора. На

этапе проектирования можно лишь

приблизительно охарактеризовать эту

величину. Оцените число строк исходного

текста задачи и число команд в

откомпилированном коде. Воспользуйтесь

контрольными примерами, написанными на

выбранном языке для работы на выбранном

оборудовании под управлением выбранной

операционной системы. Сравните результаты

контрольного примера с его размером, чтобы

получить оценку времени выполнения

откомпилированного кода.

Следующие три показателя необходимо

определить, выполняя измерения для

контрольного примера, работающего в тех же

условиях:

– затраты на контекстное переключение.

Время, которое операционная система

расходует на передачу ЦП от одной задачи к

другой (см. главу 4);

– затраты на обработку прерываний.

Время, предназначенное для обработки

прерываний;

– затраты на межзадачные

коммуникации и синхронизацию. Время,

израсходованное на посылку сообщения или

сигнализацию событию. Зависит от тех

примитивов, которые применяет задача.

Эти параметры включаются в расчет

времени ЦП, потребляемого задачей, как

было показано в примерах выше.

1. Что такое функционирование в «Реальном

масштабе времени»

2. Ядра и операционные системы реального

времени

3. Задачи, процессы, потоки

4. Основные свойства задач

5. Планирование задач

6. Синхронизация задач

7. Тестирование

8. Можно ли обойтись без ОС РВ?

9. Linux реального времени

10. Операционные системы реального

времени и Windows NT

11. Операционная система QNX

12. Проект Neutrino

13. Современные индустриальные системы,

функционирующие в режиме реального

времени

14. Организация промышленных систем

15. Аппаратная архитектура

16. Технологии VME и PCI

17. Мезонинные технологии

18. Полевые системы

19.Программное обеспечение промышленных

систем

20. Управление производством

21.UML проектирование систем реального

времени

22. Объектно-ориентированные методы и

UML

23. Метод и нотация

24. Системы и приложения реального

времени

25.Обзор нотации UML . Диаграммы UML.

Диаграммы прецедентов. Нотация UML для

классов и объектов

26. Диаграммы классов

27. Диаграммы взаимодействия

28. Диаграммы состояний

29. Пакеты

30.Диаграммы параллельной кооперации

31. Диаграммы развертывания

32. Механизмы расширения UML

33.Технологии параллельных и

распределенных систем

34. Среды для параллельной обработки

35.Поддержка исполнения в

мультипрограммной и мультипроцессорной

средах

36. Планирование задач

37.Вопросы ввода/вывода в операционной

системе

38.Технологии клиент-серверных и

распределенных систем

39. Технология World Wide Web

40.Сервисы распределенных операционных

систем

41. ПО промежуточного слоя

42. Стандарт CORBA

43. Другие компонентные технологии

44. Системы обработки транзакций

45. Разбиение на задачи

46.Вопросы разбиения на параллельные

задачи

47.Категории критериев разбиения на задачи

48.Критерии выделения задач ввода/вывода

49.Характеристики устройств ввода/вывода.

50. Асинхронные задачи интерфейса с

устройствами ввода/вывода.

51. Периодические задачи интерфейса с

устройством ввода/вывода.

52. Пассивные задачи интерфейса с

устройствами ввода/вывода.

53. Задачи-мониторы ресурсов.

54.Критерии выделения внутренних задач

55.Критерии назначения приоритетов

задачам

56. Критерии группировки задач

57. Темпоральная группировка.

58. Последовательная группировка.

59. Группировка по управлению.

60.Группировка по взаимному исключению.

61.Пересмотр проекта путем инверсии задач

62. Разработка архитектуры задач

63.Коммуникации между задачами и

синхронизация

64. Спецификация поведения задачи

65. Проектирование классов

66.Проектирование классов, скрывающих

информацию

67. Проектирование операций классов

68. Классы абстрагирования данных

69. Классы интерфейса устройства

70. Классы, зависящие от состояния

71. Классы, скрывающие алгоритмы

72. Классы интерфейса пользователя

73. Классы бизнес-логики

74. Классы-обертки базы данных

75. Внутренние программные классы

76.Применение наследования при

проектировании

77. Примеры наследования

78. Спецификация интерфейса класса

79. Детальное проектирование ПО

80. Проектирование составных задач

81. Синхронизация доступа к классам

82. Пример синхронизации доступа к классу

83. Синхронизация методом взаимного

исключения.

84. Синхронизация нескольких читателей и

писателей

85. Синхронизация нескольких читателей и

писателей с помощью монитора.

86. Синхронизация нескольких читателей и

писателей без ущемления писателей

87. Проектирование разъемов для

межзадачных коммуникаций

88. Проектирование разъема, реализующего

очередь сообщений.

89. Проектирование разъема, реализующего

буфер сообщений

90. Проектирование разъема, реализующего

буфер сообщений с ответом

91. Проектирование кооперативных задач с

использованием разъемов.

92. Логика упорядочения событий

93. Анализ производительности проекта

параллельной системы

94. Теория планирования в реальном

времени. Планирование периодических задач

95. Теорема о верхней границе

коэффициента использования ЦП.

96. Теорема о времени завершения.

97. Строгая формулировки теоремы о

времени завершения

98. Планирование периодических и

апериодических задач. Планирование с

синхронизацией задач

99. Развитие теории планирования в

реальном времени

100. Планирование в реальном времени и

проектирование. Пример применения

обобщенной теории планирования в

реальном времени

101. Анализ производительности с помощью

анализа последовательности событий

102. Анализ производительности с помощью

теории планирования в реальном времени и

анализа последовательности событий

103. Пример анализа производительности с

помощью анализа последовательности

событий .

104. Пример анализа производительности с

применением теории планирования в

реальном времени

105. Анализ производительности по теории

планирования в реальном времени и анализа

последовательности событий

106. Пересмотр проекта

107. Оценка и измерение параметров

производительности