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

План лекции:

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

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

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

Современные телекоммуникационные системы не просто должны качест­венно выполнять свои функции. Им нужно также быть совместимыми с другими подобными системами. Это важно по следующим соображениям.

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

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

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

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

 

 

Рис. 3.2. Уровнимногоуровневой модели

Нижний уровень обслуживает верхний, предоставляя ему нужные для работы примитивы и скрывая от него логику обработки этих примити­вов. Как правило, через уровни «прыгать» не принято (например, уровню N+2 нельзя напрямую обратиться к уровню N), хотя в некоторых телеком­муникационных стандартах такое встречается. Внутри себя каждый из уровней может содержать функциональные сущности («листья» декомпози­ции) и подуровни (а те, в свою очередь, содержат другие подуровни и/или функциональные сущности), — см. рис. 3.3. На этом рисунке показано, что

уровень N+1 содержит три функциональных сущности, уровень N — два подуровня. Декомпозиция «в глубину» может быть продолжена аналогич­ным образом. Еще из рис. 3.3 видно, что все соединения между уровнями, подуровнями и функциональными сущностями происходят через точки подключения, в которых определены интерфейсы взаимодействия.

Рис. 3.3. Уровни, подуровни и функциональные сущности многоуровневой модели

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

• целое полностью скрывает свои части от окружения - сами части и их связи наружу не видны;

• связи, идущие к целому извне, «протаскиваются» внутрь, через де­композиционную иерархию, к его частям (как будет показано ниже, в UML для этого используются транзитные порты и делегирующие соединители).

 

Иерархическую блочную декомпозицию можно попробовать промодели­ровать цепочкой композиций классов UML (напомню, что композиция — это «сильное» агрегирование). Но нет способа задать для экземпляров клас­сов-частей отношения, которые действуют только внутри их объекта-агре­гата (такие связи можно было бы назвать локальными ассоциациями). И уж тем более остается открытым вопрос с «протаскиванием» связей через ие­рархию декомпозиции.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

SADT является, по всей видимости, первой методологией, где был сфор­мулирован и реализован принцип блочной декомпозиции. Его авторы счи­тали, что при проектировании системы нужно поместить в модель всю ин­формацию, которая нужна, «без купюр», но одновременно расположить ее в виде, доступном для восприятия и дальнейшей работы. Это достигалось че­рез иерархическую декомпозицию — на одной диаграмме изображалось не­сколько блоков, каждый из которых далее раскрывался в следующую диа­грамму и т. д. Декомпозиция поддерживалась с учетом различных особенно­стей нотации SADT — детали см. в [3, 12]. При этом на одной диаграмме предлагалось размещать примерно семь сущностей, что соответствует пра­вилу «семь плюс/минус два», сформулированном в работе [ 13] еще в 1956 го­ду (речь идет о том, что именно это количество единиц информации опти­мально для одномоментного восприятия человеком). В SADT поддержива­лась декомпозиция экземпляров блоков, типов там не было.

В 1970-х— 1990-хгодахсоздавалсяиразвивалсяязык8ВЬдля моделирова­ния телекоммуникационных систем [14]. В этом языке использовался тот же принцип декомпозиции, что и в SADT, но к блокам добавились каналы, точ­ки соединения, сообщения и прочие атрибуты, необходимые для телекомму­никаций. В дальнейшем, в версиях SDL-92 и SDL-2000 появились типы бло­ков, наследование и другие объектно-ориентированные черты. Также были унифицированы структурные сущности — изначально, кроме блоков в SDL входили системы, подсистемы, процессы, сервисы, а теперь там есть только агенты [3, 8]. Однако, по моему мнению, эти последние новшества оказались данью моде, сделали язык более запутанным, громоздким и непонятным.

В итоге, пройдя почти тридцатилетний путь развития, язык SDL уступил место UML.

В начале 1990-х годов появилась методология ROOM [2] — объектно-ори­ентированный подход к моделированию систем реального времени. В рам­ках этого подхода был предложен способ для декомпозиции структуры сложных систем реального времени на основе типов и ролей, который впос­ледствии был использован в UML 2.O. Однако методология ROOM содержит существенно более богатые средства структурной декомпозиции, чем UML, — в частности, она включает поддержку полноценных каналов, а также сер­висных соединений, широко используемых в моделях открытых многоуров­невых сетевых протоколов.

Интерфейс. Это понятие уже рассматривалось выше, в контексте диаграмм компонент 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*); }

В UML, к сожалению, возможны только односторонние интерфейсы. Это соответствует концепции интерфейса в RPC (Remout Procedure Call), Java и других программных технологиях. Однако в системах реального времени и, в частности, в телекоммуникационных системах, дело обстоит по-другому, и есть потребность в двусторонних интерфейсах. Например, в стандарте GSM подробно описывается, что на запрос на установку соединения со стороны мобильной телефонной трубки наземная сеть может прислать либо под­тверждение, что запрос принят, либо отказ в связи с плохим финансовым по­ложением абонента, либо отказ из-за сетевых сбоев. Формат и параметры каждого из этих четырех возможных ответов тщательно описываются в стан­дарте. Естественно поместить и сам запрос, и все возможные ответы в один интерфейс. Назовем его I. Тогда две компоненты, взаимодействующие через такой интерфейс, будут связаны: одна — с интерфейсом I, другая — с интер­фейсом I*. Последний называется сопряженным интерфейсом. Например, если в интерфейсе I посылаются сообщения ml и т2, а принимаются — тЗ и т4, то в интерфейсе I* — все наоборот. Так сделано, например, в ROOM [2].

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

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

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

Порт позволяет также легко реализовать концепцию однотипного соединения. Одинаковых разъемов у аппаратного модуля может быть

* Можно считать, что в обычных диаграммах компонент порты безымянны и не показыва­ются, но на диаграммах композитных структур они показываются, их можно именовать и задавать им другие свойства.

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

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

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

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

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

Соединители должны связывать между собой только те экземпляры портов, которые совместимы. Совместимость пары портов определяется через согласованность связанной с ними пары интерфейсов. Потому что если, например, две телекоммуникационные компоненты взаимодействуют через сеть, то их интерфейсы должны быть частями одного протоко­ла. В ответ на посылку сообщения ml компонента ожидает получить со­общения т2 или тЗ или т4. А если она вместо этого получает сообщение ш5, которое вообще не предусмотрено к обработке в этой компоненте, то система в этот момент вряд ли работает правильно.

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

Согласованность двусторонних интерфейсов определяется просто: если интерфейс II является сопряженным к 12, то, значит, они совместимы и со­ответствующие экземпляры портов можно связывать соединителем 1. В дан­ном случае, когда у нас есть только односторонние интерфейсы, совмести­мость нужно как-то явно задавать, например, что II совместим с 12 и 13. При связывании двух экземпляров портов соединителем графический редактор должен проверить, являются ли их интерфейсы совместимыми. И если не являются, соединитель не должен быть создан. В UML никак не определя­ется концепция согласованности интерфейсов.

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

Исключение составляют широковещательные (broadcast) соединения, а так­же концепция сервисных соединений, реализованная, например, в ROOM [2]. Множественность соединителей используется, в основном, для ролей в других структурных классификаторах, например, в кооперациях.

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

Соединитель называется делегирующим, если он связывает порт ти­па компоненты с портом роли и роль при этом находится внутри данно- j го типа. Такой соединитель позволяет реализовывать транзитные соеди­нения, проходящие через границу типа компоненты. Ведь снаружи ком- ] поненты ее части не видны и с ними нельзя связаться непосредственно. А с помощью таких транзитных соединений это осуществимо. Пример делегирующего соединителя можно увидеть на рисунке, б - от роли

«:Видеокарта» к порту компоненты «СистемныйБлокТРС», у которого есть VGA-интерфейс.

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

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

Лекция №4.

⇐ Предыдущая234567891011Следующая ⇒

Поделиться: