Визуальное моделирование систем реального времени, часть I

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

В нашем мире растет количество различных электромеханических и электронных систем, они становятся все более сложными и все более необычными. Крупными системами такого рода являются самолеты, пароходы, автомобили, космические корабли. Небольшими системами, прочно вошедшими в нашу жизнь, являются сотовые телефоны, различная бытовая техника. А существуют еще различные управляющие системы, например, системы управления лифтами, входом в метро, а также компьютерные и телекоммуникационные сетевые системы и так далее и так далее.

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

Исторически компьютеры и программное обеспечение возникли именно как способ создать более сложные целевые электромеханические системы. Так, один из первых в мире компьютеров EDVAC (1945 год), описанный фон Нейманом в знаменитом отчете "First Draft of a report on the EDVAC", с которого, фактически, началась вычислительная техника и программирование, предназначался для управления системой противовоздушной обороны США. А конструктор первых в России ЭВМ Сергей Александрович Лебедев пришел в эту область из энергетики, решая задачи устойчивости функционирования энергетических систем.

Структурное подобие СРВ и аппаратуры

Многие СРВ структурно подобны той аппаратуре, которой они управляют, в которую они встроены. Архитектуру СРВ принято организовывать как набор параллельно работающих компонент, поскольку обработка сигнала от аппаратуры должна произойти как можно быстрее и в последовательном режиме исполнения этого не удается достичь. Получается, что определенное количество ПО-компонент управляет одной "железкой" и если таких "железок" в системе несколько, то они разбивают множество ПО-компонент на достаточно независимые группы. Вот пример.

На рис. 6.1 представлена сильно упрощенная схема программно-аппаратной СРВ - телефонной станции. Из аппаратуры на этом рисунке присутствуют: коммутатор, который осуществляет коммутацию двух абонентов станции, концентраторы, обслуживающие различные группы абонентов, и, собственно, сами абоненты, точнее их телефонные аппараты, которые соединяются с концентраторами через телефонную сеть. И концентраторы, и коммутатор имеют много однотипных входов/выходов, которые могут соединяться проводами между собой и с другими аппаратными узлами: разумеется, не каждый с каждым, а, например, выходы концентратора - с входами коммутатора, входы концентраторов - с выходами телефонных аппаратов абонентов.

В состав программной части системы входят следующие компоненты: "Концентратор1", "Концентратор2", "Коммутатор", "Абонент1" и "Абонент2". Эти компоненты, кроме реализации управляющей логики, хранят также текущие состояния соответствующих аппаратных устройств, в частности, историю работы аппаратуры, которая нужна для правильного принятия управляющих решений.

СРВ подобны аппаратуре не только в смысле разбиения на независимые компоненты, но также и в смысле связей компонент друг с другом. На рис. 6.1 можно увидеть, что сколько соединений имеют аппаратные узлы, столько же соединений имеют и соответствующие им программные компоненты. То же самое можно сказать про все другие аппаратные соединения, обозначенные на рис. 6.1. Зачем же в ПО повторять структуру соединений аппаратных компонент?

Разумеется, далеко не все связи аппаратных узлов отражаются в управляющем ПО. Но, например, в телекоммуникационных системах (к которым относится и приведенный выше пример) программные компоненты, задействованные в установлении вызова от одного абонента к другому, не только общаются в процессе поддержки этого соединения с соответствующей аппаратурой, но также и взаимодействуют друг с другом. Основной поток данных (например, закодированная речь), может и не идти через программное обеспечение по соображениям быстродействия. Но множество служебных, управляющих сигналов проходит через компоненты ПО. Для облегчения реализации этих протоколов внутри ПО в нем повторяется структура соединений аппаратуры.

Таким образом, абстракции компоненты и канала прочно вошли в телекоммуникационное ПО, сделав его структурно подобным аппаратуре, которая управляется этим ПО.

Многоуровневые открытые сетевые протоколы и блочная декомпозиция

Современные телекоммуникационные системы не просто должны качественно выполнять свои функции. Им нужно также быть совместимыми с другими подобными системами. Это важно по следующим соображениям. Во-первых, тогда можно пользоваться технологиями, реализованными другими производителями, собирая систему из готовых аппаратных и программных компонент, а самостоятельно реализуя лишь уникальную, специфическую функциональность. Это существенно экономит ресурсы разработки. Во-вторых, телекоммуникационные системы в большинстве случаев являются частями глобальной мировой телекоммуникационной сети: кому, например, нужна телефонная станция, которая хорошо обслуживает абонентов одного поселка, но не позволяет им позвонить в близлежащий город, за границу и т. д.?

Достичь легкого использования готовых компонент, а также обеспечить открытость и совместимость позволяет следование международным телекоммуникационным стандартам, которые развиваются уже не одно десятилетие такими комитетами, как ITU, ISO, ETSI и др. Большую роль в телекоммуникационных стандартах играет концепция многоуровневых открытых сетевых протоколов, стандартизованная международным комитетом ISO в модели ISO/OSI.

В рамках данных лекций не будет рассматриваться содержательный аспект этой концепции, а также конкретные телекоммуникационные стандарты ISDN, ATM, GSM и т. д. Остановимся лишь на самой идее многоуровневого сетевого протокола, которая широко используется при проектировании программно-аппаратных телекоммуникационных систем.

В основе многоуровневой модели лежит разбиение сложной телекоммуникационной функциональности на уровни или "слои" - чем выше, тем абстрактнее (см. рис. 6.2).

Нижний уровень обслуживает верхний, предоставляя ему нужные для работы примитивы и скрывая от него логику обработки этих примитивов. Как правило, через уровни "прыгать" не принято (например, уровню N+2 нельзя напрямую обратиться к уровню N ), хотя в некоторых телекоммуникационных стандартах такое встречается. Внутри себя каждый из уровней может содержать функциональные сущности ("листья декомпозиции") и подуровни (а те, в свою очередь, содержат другие подуровни и/или функциональные сущности) см. рис. 6.3. На этом рисунке показано, что уровень N+1 содержит три функциональных сущности, уровень N - два подуровня. Декомпозиция "в глубину" может быть продолжена аналогичным образом. Еще из рис. 6.3 видно, что все соединения между уровнями, подуровнями и функциональными сущностями п роисходят через точки подключения, в которых определены интерфейсы взаимодействия.

Будем называть такую декомпозицию блочной. Она отличается от других видов декомпозиции, рассмотренных при изучении UML, - например, агрегирования - следующим:

Телекоммуникационные стандарты описывают различные сетевые интерфейсы, а не просто функциональность телекоммуникационных систем. Все сказанное выше применяется для этой цели следующим образом. На рис. 6.4 показано, что на каждой из взаимодействующих сетевых сторон определяется по одному "бутерброду" из уровней. На каждом из уровней между этими сетевыми сторонами определяются свои протоколы, и нижележащие уровни служат для этих протоколов транспортной средой. Самый нижний уровень является физическим и "гоняет" по проводам электрические импульсы. Выше появляются биты, пакеты и т. д. Общение двух уровней через сеть называется peer-to-peer взаимодействием.

Сообщения двух равных (peer) уровней передаются по сети не "напрямую", а "спускаются вниз", по стеку протокола одной сетевой стороны, "обрастая" дополнительной служебной информацией, а также вспомогательными сообщениями (например, для установки различных низкоуровневых каналов, гарантирующих надежность передачи). Верхнеуровневое сообщение может быть также разбито на части и передаваться по сети этими "кусочками". На принимающей стороне эти "кусочки" должны быть вновь собраны в исходное сообщение, а само оно "поднято наверх".

Уровни, подуровни и функциональные сущности связываются друг с другом через сервисные точки (access points), в которых определяются двусторонние интерфейсы обмена сообщениями. К сервисным точкам ведут каналы снаружи блоков и от их элементов, т. е. изнутри. Ниже мы увидим, что сервисные точки моделируются портами UML 2.0.

Итак, блочная декомпозиция является важнейшим принципом моделирования сложных телекоммуникационных систем.

Композитные компоненты

В UML 2.0. есть композитные компоненты, которые можно изображать на специальных диаграммах композитных структур и которые, по сравнению с обычными UML -компонентами, изображаемыми на диаграммах компонент, имеют порты и аналоги каналов, а также могут иметь внутреннюю структуру, т. е. поддерживают блочную декомпозицию.

Блочная декомпозиция в UML усложнена поддержкой типов. Во-первых, композитные компоненты являются типами компонент, а во-вторых, внутри себя они состоят из частей, которые принадлежат к другим типам компонент. Давайте посмотрим, чем блочная декомпозиция типов отличается от экземплярной блочной декомпозиции, которая, фактически, и рассматривалась в предыдущем разделе.

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

Пусть теперь создается сеть из двадцати телефонных станций, для двадцати поселков. Использовать в каждом поселке абсолютно уникальную разработку - очень накладно. Появляется несколько типов станций, которыми и "покрываются" особенности, имеющиеся в различных населенных пунктах. Каждый тип станции внутри себя устроен одинаково.

Экземплярная блочная декомпозиция не подходит для моделирования структуры сложных СРВ, поскольку при этом часто возникает потребность определять множество типовых узлов и на их основе конструировать другие типы узлов. Например, типовая телефонная станция может содержать несколько однотипных пользовательских компьютеров для рабочих мест операторов и один сервер. Типовой пользовательский компьютер (тип компоненты "ТиповаяРабочаяСтанция"), к примеру, должен включать в себя 15-дюймовый монитор, процессор по быстродействию не ниже Pentium IV 1,6 Гц, сетевую карту, а в некоторых случаях еще и CD-устройство. Все это изображено на рис. 6.5, выполненном в нотации диаграмм композитных структур UML 2.0.

В этом примере на верхнем уровне блочной декомпозиции можно увидеть два типа компонент - "ТиповаяРабочаяСтанция" и "ТиповойСервер". Они состоят из частей, среди которых "МониторТРС" и "МониторТС"Сокращения в именах на рис. 6.5 расшифровываются так: ТРС - Типовая Рабочая Станция, а ТС - Типовой Сервер. имеют одинаковый тип - "15ДМонитор". Второй уровень представлен спецификацией компонентного типа "СистемныйБлокТРС", используемого в определении типа "ТиповаяРабочаяСтанция". Наконец, на третьем уровне представлен тип компоненты "МатеринскаяПлатаТРС", который используется при определении типа "ТиповаяРабочаяСтанция". (Этот тип я раскрывать дальше не стал, ограничившись спецификацией портов и интерфейсов. Ведь где-то надо остановиться!) Все типы компонент, показанные на этом рисунке, - "ТиповаяРабочаяСтанция", "ТиповойСервер", "СистемныйБлокТРС", "МатеринскаяПлатаТРС" - являются композитными компонентами.

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

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

Роли компонент (далее - просто роли) обязательно имеют тип и служат "гнездами" для подстановки конкретных экземпляров своих типов компонент. Например, в гнездо "ПамятьТРС" можно подставить от 2 до 8 экземпляров типа "МикросхемыПамяти". А в безымянное гнездо в типе "СистемныйБлокТРС", имеющее тип "CD-устройство", можно подставить один экземпляр этого типа или ни одного.

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

Роль отличается от типа тем, что является контекстно-зависимым определением набора экземпляров. В самом деле, тип (класс, тип компоненты) определяет экземпляры, которые могут появиться практически в любом месте системы (естественно, в соответствии с правилами видимости). А экземпляры ролей могут появляться только в определенной композитной компоненте. В целом контекстной свободы у типа существенно больше, чем у роли.

Имя роли задается так:

<идентификатор1>: <идентификатор2>,

где <Идентификатор1> - это имя роли, а <Идентификатор2> - имя ее типа. Тот или иной идентификатор могут быть опущены - см. рассуждения об именах объектов в лекции про UML.

На рис. 6.5 почти все роли не имеют имен, а содержат лишь указания на типы своих компонент - здесь этого оказалось достаточно. Даны имена только двум ролям - "МониторТРС: 15ДМонитор" в компоненте "ТиповаяРабочаяСтанция" и "СистемныйБлокТС" в компоненте "ТиповойСервер". В обоих этих компонентах задействованы узлы одинакового типа, поэтому естественно дать им разные имена. Еще я задал имя Pentium-процессору - Процессор ТРС, - чтобы подчеркнуть, что речь идет именно о процессоре.

Имена ролей в разных композитных компонентах могут совпадать, в том числе и для ролей одинаковых типов. Ведь композитная компонента является закрытым пространством имен. Однако, во избежание путаницы, так лучше не делать.

Далее, для простоты изложения, я часто буду называть и композитные компоненты, и роли, из которых они состоят, просто компонентами. Надеюсь, что читатель не запутается и из контекста поймет, что означает очередная "компонента".

Интерфейс

Это понятие уже рассматривалось выше, в контексте диаграмм компонент UML. Теперь оно будет изучено более детально. Интерфейс (interface) - это конструкция, которая позволяет компоненте, скрывая ее внутреннее устройство, предоставить вовне определенный способ обращения к своей функциональности. Компонента может сделать доступными через свой интерфейс следующие примитивы:

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

С обращением к переменной - то же самое. Как правило, реализация обращений к переменной интерфейса компоненты происходит через служебные операции set (для установки значения) и get (для чтения значения), которые скрыты от пользователя интерфейса.

Асинхронное взаимодействие - компонента послала запрос и, не дожидаясь ответа на него, продолжила свою работу. Классическим способом реализовать асинхронное взаимодействие является посылка сообщения. Компонента реализует интерфейс с сообщениями, когда умеет их обрабатывать.

Рассмотрим пример. Ниже представлен интерфейс Connect, который могут реализовывать компоненты "Концентратор1" и "Концентартор2" из примера на рис. 6.1, а использовать - компоненты "Абонент1" и "Абонент2". Последние с его помощью устанавливают связь со станцией в случае исходящего вызова (операция EstablishConnect ), устанавливают/просматривают статус соединения (операции SetStatus/GetStatus ), прерывают соединение (операция ReleaseConnect ).

Interface Connect{
int EstablishConnect (int status);
int SetStatus (int status);
int GetStatus ();
int ReleaseConnect(connection*);}

Порт

Что такое интерфейс - понятно. Тем более, что интерфейс присутствует в общеиспользуемых языках программирования, таких как Java, а также в компонентных технологиях, например COM, Java Beans и пр.

Порт (port) - это точка, через которую происходит взаимодействие компоненты с окружающей ее средой. Именно с портом, а не с компонентой вообще связываются интерфейсы, которые компонента реализует и/или требует для своей работыМожно считать, что в обычных диаграммах компонент порты безымянны и не показываются, но на диаграммах композитных структур они показываются, их можно именовать и задавать им другие свойства.. Порт аналогичен аппаратному разъему, например, USB-разъему компьютера.

Порт позволяет также легко реализовать концепцию однотипного соединения. Одинаковых разъемов у аппаратного модуля может быть много, например, три USB-разъема у компьютера. Чтобы компактно промоделировать эту ситуацию, можно сказать, что у компоненты "Компьютер" имеется порт с множественностью три, реализующий USB-интерфейс. А поскольку у композитных компонент часто возникают однотипные соединения, то множественный порт оказывается крайне полезной конструкцией. На рис. 6.5, в порт компоненты "МатеринскаяПлатаТРС" с интерфейсом DDR (для подключения микросхем оперативной памяти) имеет множественность 8, порты с интерфейсами PCI и IDE имеют множественность 2.

Порт принадлежит типу компоненты, а у роли компоненты могут быть, соответственно, экземпляры порта. У порта может быть имя, хотя на рис. 6.5 такие имена отсутствуют, а есть только имена интерфейсов, соединенных с портами. Использовать или нет имена у портов - вопрос вкуса. Я придерживаюсь мнения, что не стоит загромождать диаграмму какой-либо информацией без настоятельной необходимости.

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

Соединитель

Концепция соединения очень важна в СРВ, в частности, в телекоммуникационных системах. Как было показано выше, многочисленные соединения между узлами телекоммуникационной аппаратуры "перекочевывают" в ПО телекоммуникационных систем. И эти соединения должны вести себя также, как и аппаратные соединения: их нужно уметь устанавливать, поддерживать, завершать (в том числе, и аварийно), восстанавливать после сбоя и т. д. Кроме того, все чаще именно компоненты ПО, а не аппаратура, участвуют в непосредственной передаче данных, реализуя протоколы верхних уровней стека сетевых протоколов. При этом они часто распределены по сети и пользуются готовыми программно-аппаратными реализациями нижних уровней для передачи данных. Так что возникает надобность "прокладывать" каналы напрямую от одной ПО-компоненты к другой.

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

Соединители должны связывать между собой только те экземпляры портов, которые совместимы. Совместимость пары портов определяется через согласованность связанной с ними пары интерфейсов. Потому что если, например, две телекоммуникационные компоненты взаимодействуют через сеть, то их интерфейсы должны быть частями одного протокола. В ответ на посылку сообщения m1 компонента ожидает получить сообщения m2 или m3 или m4. А если она вместо этого получает сообщение m5, которое вообще не предусмотрено к обработке в этой компоненте, то система в этот момент вряд ли работает правильно.

Однако понятие согласованности интерфейсов в UML не определяется формально.

Множественность на концах соединителя аналогична множественности концов ассоциации. Ведь роли компонент, которые связывает соединитель, похожи на классы, которые связывает ассоциация, - и те и другие определяют наборы экземпляров. Соответственно, ассоциация переходит в связь между экземплярами, и соединитель - тоже. Однако в СРВ не приняты связи "один-ко-многим" и уж тем более "многие-ко-многим".

В примере на рис. 6.5 концы всех соединителей имеют множественность 0..1, и на диаграммах рассматриваемого примера она не показана. Значение множественности 0 реализуется, когда экземпляр компоненты не имеет данного соединения. Когда он его устанавливает, то реализуется значение множественности, равное единице.

Соединитель называется делегирующим, если он связывает порт типа компоненты с портом роли и роль при этом находится внутри данного типа. Такой соединитель позволяет реализовывать транзитные соединения, проходящие через границу типа компоненты. Ведь снаружи компоненты ее части не видны и с ними нельзя связаться непосредственно. А с помощью таких транзитных соединений это осуществимо. Пример делегирующего соединителя можно увидеть на рис. 6.5, б - от роли ":Видеокарта" к порту компоненты "СистемныйБлокТРС", у которого есть VGA -интерфейс.

Порты компонент, которые соединяются делегирующими соединителями с ролями внутри этих компонент, называются транзитными. Порт с интерфейсом VGA на рис. 6.5, б является транзитным. Порты, которые не соединены с частями компоненты, называются оконечными. Они ведут, например, к той части компоненты, которая не состоит из других компонент, то есть к собственному поведению компоненты. Собственное поведение часто определяют с помощью диаграмм конечных автоматов - это будет обсуждаться в следующей лекции. На рис. 6.5, б оконечным портом является тот, который предназначен для включения в электрическую сеть (с интерфейсом 220В).

Выводы

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

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

Композитные компоненты UML незаменимы при разработке структурно сложных СРВ, в частности, сложных телекоммуникационных систем. Однако на практике встречается много структурно простых СРВ. Такие системы могут быть глубоко встроенными в аппаратуру и управлять одной-двумя "железками", имея всего несколько программных компонент и небогатый внешний интерфейс. При этом системы могут быть достаточно сложны - например, реализовывать сложные математические алгоритмы. Однако при разработке таких систем, наверное, "городить огород" с UML-компонентами, портами, соединителями и пр. не стоит…

Реактивные системы

Выше были рассмотрены средства моделирования UML 2.0 структуры СРВ. Теперь перейдем к моделированию поведения СРВ.

Рассмотрим класс СРВ под названием реактивные системы (reactive systems). Такие системы обладают следующими свойствами.

Считая, что первые четыре свойства в достаточной мере очевидны, рассмотрим лишь последнее свойство - зависимость поведения системы от истории. Вот пример. Пусть некоторый человек едет в переполненном автобусе. Другой человек ему наступает на ногу. Первый делает вид, что не замечает, досадливо морщась. Когда тот же человек наступает ему на ногу во второй раз, первый может заметить вслух, что пора бы прекратить это делать. Но когда это же происходит в третий раз, в автобусе происходит скандал… В моменты, непосредственно предшествующие "наступанию" на ногу - внешнему событию для компоненты "Потерпевший" - данная компонента находилась в трех разных состояниях, напрямую зависящих от предыдущих событий. И ее реакция на одно и то же событие в этих состояниях разнаяИдея данного примера взята из [6.5]..

Итак, в компонентах реактивных систем целесообразно заводить различные состояния, фиксирующие определенный момент в истории их жизни. И обработка одних и тех же внешних событий компонентами в этих состояниях будет различной.

Среди СРВ встречается большое количество реактивных систем. Однако, не все СРВ таковы. Например, какой-нибудь шифратор сетевых сообщений просто обрабатывает входной поток внешних сообщений, шифруя их и выдавая дальше, в сеть. В нем может быть всего несколько состояний: старт, нормальная работа, завершение работы, переполнение. Нет никакой прерываемости, отсутствует зависимость от истории, взаимодействие с окружением синхронное.

В следующей лекции будет рассмотрено, как поведение реактивных компонент моделируется с помощью диаграмм конечных автоматов UML 2.0.

Контрольные вопросы