- •2. Ядра и операционные системы реального времени
- •2.1. Задачи, процессы, потоки
- •2.2. Основные свойства задач
- •2.3. Планирование задач
- •2.4. Синхронизация задач
- •2.5. Тестирование
- •2.6. Можно ли обойтись без ОС РВ?
- •3. Обзор некоторых операционных систем реального времени
- •3.1. Linux реального времени
- •3.2. Операционные системы реального времени и Windows
- •3.3. Операционная система QNX
- •3.4. Проект Neutrino
- •4.1. Организация промышленных систем
- •4.2. Аппаратная архитектура
- •4.3. Стандарты шин
- •4.4. Технологии VME и PCI
- •4.5. Мезонинные технологии
- •4.6. Полевые системы
- •4.7. Программное обеспечение промышленных систем
- •4.8. Управление производством
- •Часть 2. ПРОЕКТИРОВАНИЕ СРВ
- •5. UML проектирование систем реального времени
- •5.1. Объектно-ориентированные методы и UML
- •5.2. Метод и нотация
- •5.3. Системы и приложения реального времени
- •6. Обзор нотации UML
- •6.1. Диаграммы UML
- •6.2. Диаграммы прецедентов
- •6.3. Нотация UML для классов и объектов
- •6.4. Диаграммы классов
- •6.5. Диаграммы взаимодействия
- •6.6. Диаграммы состояний
- •6.7. Пакеты
- •6.8. Диаграммы параллельной кооперации
- •6.9. Диаграммы развертывания
- •6.10. Механизмы расширения UML
- •7.1. Среды для параллельной обработки
- •7.2. Поддержка исполнения в мультипрограммной и мультипроцессорной средах
- •7.3. Планирование задач
- •7.4. Вопросы ввода/вывода в операционной системе
- •7.6. Технология World Wide Web
- •7.7. Сервисы распределенных операционных систем
- •7.8. ПО промежуточного слоя
- •7.9. Стандарт CORBA
- •7.10. Другие компонентные технологии
- •7.11. Системы обработки транзакций
- •8. Разбиение на задачи
- •8.1. Вопросы разбиения на параллельные задачи
- •8.2. Категории критериев разбиения на задачи
- •8.3. Критерии выделения задач ввода/вывода
- •8.4. Критерии выделения внутренних задач
- •8.5. Критерии назначения приоритетов задачам
- •8.6. Критерии группировки задач
- •8.7. Пересмотр проекта путем инверсии задач
- •8.8. Разработка архитектуры задач
- •8.9. Коммуникации между задачами и синхронизация
- •8.10. Спецификация поведения задачи
- •9. Проектирование классов
- •9.1. Проектирование классов, скрывающих информацию
- •9.2. Проектирование операций классов
- •9.3. Классы абстрагирования данных
- •9.4. Классы интерфейса устройства
- •9.5. Классы, зависящие от состояния
- •9.6. Классы, скрывающие алгоритмы
- •9.7. Классы интерфейса пользователя
- •9.10. Внутренние программные классы
- •9.11. Применение наследования при проектировании
- •9.12. Примеры наследования
- •9.13. Спецификация интерфейса класса
- •10. Детальное проектирование ПО
- •10.1. Проектирование составных задач
- •10.2. Синхронизация доступа к классам
- •10.4. Логика упорядочения событий
- •11.1. Теория планирования в реальном времени
- •11.2. Развитие теории планирования в реальном времени
- •11.5. Пример анализа производительности с помощью анализа последовательности событий
- •11.6. Пример анализа производительности с применением теории планирования в реальном времени
- •11.8. Пересмотр проекта
- •11.9. Оценка и измерение параметров производительности
- •12. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
220 |
Пример класса-обертки базы данных приведен на рис.9.9. В бан- ковской системе все устойчивые данные хранятся в базе, поэтому сущностные классы Банковского Сервера отображаются как на отно- шение базы данных, так и на класс-обертку. Рассмотрим, к примеру,
сущностный класс Дебетовая Карточка из аналитической модели (рис.9.9а). Поскольку информация с карточки хранится в реляцион- ной базе данных, этому классу соответствует отношение в базе. Атри- буты класса отображаются на атрибуты отношения. Кроме того, надо указать первичный ключ; мы выбрали атрибут идентификатор Кар- точки, так как он однозначно определяет строку отношения (рис.9.96). Требуется также внешний ключ для представления ассо-
циации Клиент владеет Дебетовой Карточкой.
Внешний ключ является первичным в таблице, связанной с дан- ной. Он соответствует ассоциации между классами и используется для навигации между таблицами. Первичный ключ для отношения Клиент – это НСС Клиента (номер социального страхования), так что именно он становится внешним в отношении Дебетовая Карточка.
Необходимо спроектировать класс-обертку Дебетовая Карточ- ка (рис.9.96), в котором будут следующие операции: создать, прове-
рить, проверитьСуточныйЛимит, обнулитьИтог, обновить, чи-
тать и удалить. Эти операции инкапсулируют операторы SQL для доступа к отношению Дебетовая Карточка. Обратите внимание, что атрибуты класса разрешается обновлять независимо, поэтому для ка- ждого атрибута имеется своя операция обновить. Вызов любой опе- рации приводит к выполнению некоторого оператора SQL.
9.10. Внутренние программные классы
Внутренние программные классы скрывают решения разработ-
чика, которые могут со временем измениться. Обычно они создаются на поздних стадиях процесса проектирования. Определить их из ана- литической модели, относящейся к предметной области, невозможно.
Внутренние программные классы инкапсулируют различные структуры данных (стеки, очереди, таблицы данных), выбранные проектировщиком. Примерами внутренних классов являются также классы-разъемы.
9.11. Применение наследования при проектировании
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
221 |
Наследование полезно при проектировании двух похожих клас- сов, то есть таких, у которых много общих черт. На этапе проектиро- вания архитектуры его нужно иметь в виду, чтобы впоследствии на этапах детального проектирования и кодирования можно было по- вторно использовать тот же или слегка видоизмененный код. Насле-
дование задействуют и с целью сделать проект более удобным для сопровождения – такое применение оченъ упрощает инкрементную модификацию программы.
9.11.1.Иерархии классов. Иерархии классов (называемые также иерархиями обобщения/специализации или иерархиями наследова- ния) допустимо разрабатывать сверху вниз, снизу вверх или в обоих направлениях. При разработке сверху вниз проектируется класс, ко- торый включает характеристики, общие для всех его наследников. В ходе специализации этого класса формируются подклассы со специ- фическими особенностями. Можно поступать и наоборот, если в пер- воначальном проекте есть классы, имеющие как общие черты (опера- ции или атрибуты), так и некоторые отличия. В таком случае общие свойства переносятся в суперкласс и наследуются подклассами.
Следует отметить, что при использовании наследования внут- реннее устройство родительских классов видимо подклассам, такой вид повторного применения называется прозрачным ящиком, нару- шающим концепцию инкапсуляции (сокрытия-информации). Реали- зация класса-потомка тесно связана с реализацией родительского класса, что бывает причиной затруднений в глубоких иерархиях на- следования. Изменение класса, расположенного на верхнем уровне иерархии, может затронуть всех его потомков. По этой причине стоит ограничить глубину иерархии классов.
9.11.2.Абстрактные классы. У абстрактного класса не может быть экземпляров, поэтому он используется как шаблон для создания классов, а не объектов. Иными словами, он способен выступать толь- ко в роли суперкласса, который определяет общий интерфейс для всех своих подклассов. Абстрактная операция – это операция, кото- рая объявлена, но не реализована в абстрактном классе. Абстрактный класс должен иметь хотя бы одну абстрактную операцию.
Абстрактный класс оставляет реализацию некоторых операций своим подклассам. Подкласс в состоянии реализовывать операции, придерживаясь интерфейса, заданного своим абстрактным родите- лем. Различные подклассы абстрактного класса могут определять
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
222 |
разные реализации одной и той же операции. Таким образом, абст- рактный класс задает интерфейс в форме набора абстрактных опе- раций. Подклассы реализуют этот интерфейс и расширяют его, до- бавляя собственные операции.
Некоторые операции разрешается осуществлять в самом абст- рактном классе, особенно тогда, когда их реализация в некоторых или всех подклассах должна быть одинаковой. Иногда абстрактный класс определяет реализацию операции по умолчанию. В подклассе эту операцию можно при необходимости заместить. Так делают, когда некий подкласс должен обрабатывать особый случай, для которого реализация по умолчанию не годится.
9.11.3. Полиморфизм и динамическое связывание. Слово «поли-
морфизм» в переводе с греческого означает «многообразие форм». В объектно-ориентированном проектировании полиморфизм использу- ется, когда в различных классах должна существовать операция с од- ним и тем же именем. Ее спецификация во всех классах одинакова, но реализация может быть различной: это дает возможность во время выполнения использовать вместо одного объекта другой с тем же ин- терфейсом.
Динамическое связывание применяется совместно с полимор- физмом для ассоциирования запроса с объектом и одной из его опе- раций во время исполнения. При статическом связывании (типичный случай в процедурных языках) ассоциация запроса с операцией уста- навливается во время компиляции, ее нельзя впоследствии изменить. При динамическом связывании, напротив, запрос может сначала вы- полняться операцией одного объекта, а потом операцией другого объекта.
9.12. Примеры наследования
Ниже мы приведем три примера наследования, иллюстрирую- щих применение суперклассов и подклассов, полиморфизма и дина- мического связывания, а также абстрактных классов.
9.12.1. Примеры суперклассов и подклассов. В банковской сис-
теме класс Счет имеет два атрибута: номерСчета и баланс. Посколь- ку счета нужно открывать и закрывать, дебетовать и кредитовать, а также считывать баланс, то определяются следующие операции:
§ открыть (номерСчета : Integer)
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
223 |
§закрыть ()
§читатьБаланс () : Real
§кредитовать (сумма : Real)
§дебетовать (сумма : Real)
Банк работает с двумя видами счетов: чековыми и сберегатель- ными. Ситуация выглядит вполне подходящей для применения на- следования: нужно создать обобщенный суперкласс счета и его спе- циализированные подклассы для чековых и сберегательных счетов. На данном этапе следует ответить на такие вопросы: какие обобщен- ные атрибуты и операции должны быть в суперклассе и какие специ- ализированные атрибуты – у сберегательного и чекового счета? Дол- жен ли суперкласс быть абстрактным?
Но прежде чем отвечать, надо выявить сходство и различие ме- жду чековыми и сберегательными счетами. Сначала рассмотрим ат- рибуты. Ясно, что у любого счета есть номер и баланс, следователь- но, эти атрибуты можно обобщить и поместить в класс Счет. С дру- гой стороны, в данном банке на сберегательные счета начисляются проценты, а на чековые - нет. Нужно знать сумму начисленных про- центов, поэтому в классе Сберегательный Счет объявляется атрибут накопительныйПроцент. Кроме того, со сберегательного счета раз- решается безвозмездно снимать деньги не более трех раз в месяц, что приводит к объявлению атрибута счетчикДебетований. Еще объяв- ляются два статических атрибута класса, их значение одинаково для всех объектов данного класса: максимальноеЧислоБесплатныхДебе- тований (сколько раз в месяц можно снимать деньги со счета, не оп- лачивая банковские услуги; начальное значение равно 3) и платаБан- ку (сумма, выделяемая банку за каждое снятие денег сверх лимита; равна 1,5 доллара). Кроме того, в случае чековых счетов желательно знать, какая сумма была положена в последний раз. Поэтому в классе Чековый Счет объявляется атрибут суммаПоследнегоВклада.
И для Чекового Счета, и для Сберегательного Счета нужны те же операции, что и для обобщенного класса Счет: открыть, закрыть, читатьБаланс, кредитовать, дебетовать. Интерфейс этих операций оп- ределен в суперклассе Счет и наследуется обоими подклассами. Опе- рации открыть, закрыть и кредитовать выполняются одинаково и для чековых, и для сберегательных счетов, поэтому их реализацию мож- но определить в классе Счет и унаследовать в подклассах. Что каса-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
224 |
ется операции дебетовать, то Чековый Счет в состоянии унаследовать ее реализацию от класса Счет. Но для Сберегательного Счета она осуществляется иначе: помимо уменьшения баланса необходимо еще увеличить счетчик Дебетований и вычесть из баланса платуБанку, ес- ли число дебетований превысило лимит. Нужна также дополнитель- ная операция обнулитьСчетчикДебетований, которая сбрасывает зна- чение счетчикаДебетований в начале каждого месяца.
Рис.9.10. Пример суперкласса и подклассов
На первый взгляд кажется, что операция читатьБаланс для обоих классов одинакова, но более внимательное рассмотрение пока- зывает, что это не так. При обращении к чековому счету требуется получить баланс и сумму последнего вклада, а для сберегательного счета нужен баланс и накопительный процент. Следовательно, необ- ходимо ввести разные операции чтения. В суперклассе определяется обобщенная операция читатьБаланс, которая наследуется и чеко- вым, и сберегательным счетом. Затем в класс Сберегательный Счет
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
225 |
добавляется операция читать НакопительныйПроцент, а в класс
Чековый Счет – операция читатьСуммуПоследнегоВклада.
Проект иерархии класса Счет показан на рис.9.10 и прокоммен- тирован ниже.
Проект подкласса «Чековый Счет»
1. Атрибуты подкласса Чековый Счет:
– наследует атрибуты номерСчета и баланс. Оба атрибута объ- явлены защищенными в суперклассе Счет, поэтому они видимы в подклассах;
– добавляет атрибут суммаПоследнегоВклада. 2. Операции подкласса Чековый Счет:
–наследует операции открыть, закрыть, читатьБаланс, кре- дитовать и дебетовать;
–добавляет операцию читатьСуммуПоследнегоВклада () : Real
Проект подкласса «Сберегательный Счет»
1. Атрибуты подкласса Сберегательный Счет:
–наследует атрибуты номерСчета и баланс;
–добавляет атрибуты накопительныйПроцент и счетчик Дебе- тований;
–добавляет статические атрибуты класса максимальное Число-
БесплатныхДебетований и платаБанку. Статические атрибуты в
UML подчеркиваются (см. рис.9.10).
2. Операции подкласса Сберегательный Счет:
–наследует спецификацию и реализацию операций открыть,
закрыть, читатьБаланс и кредитовать;
–наследует спецификацию операции дебетовать, но переопре- деляет ее реализацию: уменьшает баланс счета и взимает плату бан- ку, если превышен месячный лимит бесплатных дебетований;
–добавляет операции:
–начислитьПроцент (процентнаяСтавка : Real). Ежедневное начисление процентов;
–читатьНакопительныйПроцент () : Real;
–обнулитьСчетчикДебетований (). Сбрасывает счетчикДе-
бетований в нуль в начале каждого месяца.
9.12.2. Пример полиморфизма и динамического связывания. Рас-
смотрим теперь создание объектов этих классов, а также пример по- лиморфизма и динамического связывания.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
226 |
begin
private account : Счет;
Предложить клиенту ввести тип счета и снимаемую сумму
if клиент выбрал чековый счет
then -- Записать в переменную account чековый счет клиента.
. . .
account := customerCheckingAccount;
. . .
elseif клиент выбрал сберегательный счет then -- Записать в переменную account
сберегательный счет клиента.
. . .
account := customerSavingsAccount; endif;
. . .
-- Дебетовать счет account, который может быть чековым или сберегательным. account.дебетовать (сумма);
. . .
end;
В этом примере, если выбран чековый счет, то в переменную account записывается объект класса Чековый Счет. При выполнении оператора account. дебетовать вызывается операция Чекового Счета. Если же указан сберегательный счет, то оператор account.дебетовать приведет к вызову операции Сберегательного Счета. Для чековых и сберегательных счетов выполняются разные варианты операции де- бетовать, в частности для сберегательного счета из баланса допол- нительно вычитается плата банку, если превышен месячный лимит дебетований.
Следует отметить, что объекту типа Счет можно присвоить объект типа Чековый Счет или Сберегательный Счет, но обратное неверно. Дело в том, что каждый Чековый Счет является Счетом, равно как и каждый Сберегательный Счет является Счетом, однако нельзя сказать, будто каждый Счет является Сберегательным, он может быть и Чековым.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
227 |
9.12.3. Пример наследования абстрактному классу. Рассмотрим класс Техническое Обслуживание из системы круиз-контроля и мо- ниторинга. Классы Замена Масла, Замена Воздушного Фильтра и Станционное ТО можно проектировать отдельно, но, если сделать их подклассами класса Техническое Обслуживание, кода придется пи- сать гораздо меньше. Иерархия обобщения/специализации для класса
Техническое Обслуживание показана на рис.9.11.
Рис.9.11. Пример абстрактного суперкласса и подклассов
Суперкласс Техническое Обслуживание является абстрактным, в нем есть две операции: сбросить и проверить. Обе операции исполь- зуют инкапсулированный тип данных начальныйПробег, который ра- вен общему пути, пройденному к моменту предыдущего техническо- го обслуживания. Операция сбросить вызывает операцию читать объекта Путь, которая возвращает значение полного Пробега, а затем присваивает это значение атрибуту начальный Пробег. Операция про- верить абстрактная, она специфицирована в классе Техническое Об- служивание, но реализована только в его подклассах.
Любой подкласс, допустим Замена Масла, наследует структуру класса Техническое Обслуживание, в том числе определение атрибута начальныйПробег и полное определение (спецификацию и реализа- цию) операции сбросить, а также спецификацию абстрактной опера- ции проверить. Но реализацию последней операции подкласс Замена
www.pdffactory.com