Методология системотехнического проектирования электронных и радиоэлектронных средств (в двух частях)

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

На рисунке 5.9 приведен пример диаграммы последовательности для операции выдачи книги. Эта диаграмма связана с представленным выше вариантом использования, но содержит дополнительную информацию.

Рисунок 5.9 – UML-диаграмма последовательности

Диаграмма классов. В основе UML лежит понятие класса; для его представления предназначены диаграммы классов. Можно считать, что класс – это множество объектов (реальных или виртуальных), обладающих одинаковыми

126

характеристиками и семантикой. Объект может быть практически чем угодно, представимым программными средствами. Типичный класс описывает структуру и поведение объектов класса.

Определение класса содержит три основных компонента (в числе прочих):

–атрибуты – структурные свойства класса;

–операции – поведенческие свойства класса;

–обязанности – обязательства класса.

Обычно между классами имеются связи. Самая простая структурная связь называется ассоциацией. На рисунке 5.10 показана простая ассоциация между двумя классами – «Работник» и «Компания». Линия, соединяющая два класса, может быть снабжена стрелкой; если же стрелка отсутствует, подразумевается двусторонняя связь. Характер ассоциации можно также описать с помощью треугольника. В этом случае ассоциация читается следующим образом: «Работник работает в компании» и «Компания нанимает работника». Наконец, автор может указать кратность ассоциации, которая определяет её численные аспекты и записывается отдельными числами или в той или иной сокращённой нотации. Например, запись 0..2 означает любое значение от 0 до 2, а символ звездочки (*) интерпретируется как «много». Таким образом, в нашем примере звездочка и число «1» означают, что работник работает только в одной компании, а компания может нанять много работников.

Рисунок 5.10 – Пример ассоциации классов

Между классами могут существовать связи ещё двух типов: обобщение и зависимость. Обобщение описывает таксономическую связь между частным и общим классами. На рисунке 5.11 изображены обобщения, связывающие три класса: клиент, корпоративный клиент и клиент – физическое лицо. В данном случае как корпоративные клиенты, так и физические лица являются частными случаями более общего класса «Клиент». Такая связь изображается в виде стрелки с широким острием. На данной диаграмме представлены также атрибуты и операции всех классов.

Частные классы, связанные отношением обобщения с более общим классом, наследуют атрибуты и операции своего родителя. Следовательно, класс «Корпоративный клиент»обладаетнетолькособственнымиатрибутами иоперацией, нотакже атрибутами Name и Adress и операцией getCreditRating(). То же самое справедливо и для класса «Клиент–физическое лицо».

Третий тип связи – зависимость – применяется в ситуации, когда в описании или реализации одного класса используется другой. Следует отметить, что отношение зависимости может существовать не только между классами, но и между другими элементами UML.

127

Язык моделирования SysML

Хотя язык UML применялся к системам, включающим как программные, так и аппаратные компоненты, постепенно стало ясно, что более эффективным был бы вариант UML, разработанный специально для таких программно-аппаратных систем. К томужепомереразвитияв 1990-хгодах системной инженерии и особенно построения архитектуры систем пришло понимание, что наличие формального языка моделирования полезно закрепить в виде единого стандарта. В 2001 году Международный советпосистемной инженерии (TheInternationalCouncil onSystems Engineering – INCOSE) взял на себя разработку стандартного языка моделирования. Отдавая должное популярности и гибкости UML, разработчики взяли за основу именно этот язык, точнее, его версию 2.0. В этом мероприятии приняли участие группа OMG и сформированная в 2001 году специальная группа по системной инженерии (Systems Engineering Domain Special Interest Group). Действуя совместно,

обе организации разработали и опубликовали расширение UML для системной инженерии – язык моделирования систем (Systems Modeling Language), сокращенно

SysML.

Пожалуй, наиболее существенное различие между UML и SysML заключается в том, что пользователь SysML может не быть специалистом в области объектноориентированного анализа и проектирования. SysML поддерживает многие традиционные принципы, возможности и модели системной инженерии. На рисунке 5.13 представлены диаграммы, составляющие основу этого языка.

Рисунок 5.13 – Модели SysML

Добавлена новая категория, включающая всего одну диаграмму – диаграмму требований. Не подверглись изменениям только четыре из 13 диаграмм UML: пакетов, вариантов использования, состояний и последовательности. Диаграммы, опирающиеся на объектно-ориентированные методологии и подходы, исключены.

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

129

Диаграмма требований. В UML требования к программному обеспечению представлены главным образом диаграммами вариантов использования [2, 3, 9]. Однако это в основном функциональные требования; для нефункциональных требований в UML нет явного представления. Чтобы восполнить данное упущение, были разработаны стереотипы, но в SysML реализована новая модель, специально ориентированная на требования этого вида.

На рисунке 5.14 приведен простой пример диаграммы требований. Основное требование – максимизация скорости самолета. Это требование уровня системы, имеющеетри атрибута –идентификатор, тексти единицуизмерения. Текстсодержит «классическое» описание конкретного требования. Для требования уровня системы имеется метод верификации –в данном случаеиспытание, обозначенное «TestCase». Детальные сведения об испытании AircraftVelocityTest находятся где-то в другом месте.

Рисунок 5.14 – Диаграмма требований в SysML

Этотребованиеуровня системы может порождать ряд производных требований, как правило, ассоциированных с подсистемами. На рисунке 5.14 показаны три производных требования: тяга двигателя, вес самолета и подъёмная сила самолета. У этих требований также имеются атрибуты и характеристики, хотя на данной диаграмме они не показаны.

Мы видим на рисунке связь «Удовлетворяет». Так обозначается механизм или объект, удовлетворяющий производному требованию. В случае тяги двигателя за удовлетворение производного требования отвечает подсистема двигателя.

130

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

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

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

Напомним, что обычно поведение представляет собой деятельность или действие. Привязка структуры соединяет (или привязывает) логические структуры с физическими (и наоборот). Этот механизм даёт возможность связывать компоненты логического описания системы (обычно представлены логическими блоками) с компонентами физического описания (обычно представлены физическими блоками и пакетами). Наконец, привязка потока объектов связывает поток элементов (на структурной диаграмме) с дугой потока объектов (на диаграмме деятельности). На многих диаграммах SysML привязки можно распознать по пунктирной стрелке.

Диаграмма определений блоков. В UML базовым элементом является класс, а экземпляры класса представлены объектами. Посколькуэти термины слишком тесно ассоциируются с разработкой ПО, то в SysML для базового элемента употребляется другое название – блок. Структура и семантика блока почти такие же, как у класса. Блок содержит атрибуты, может ассоциироваться с другими блоками и описывать набор выполняемых деятельностей или раскрываемых поведений.

Блоки применяются для представления статической структуры системы. Они могут представлять как логические (функциональные), так и физические элементы. Последние можно отнести к разным типам в соответствии с физическим воплощением – оборудование, программное обеспечение, документация и т.д. На рисунке 5.15 изображён пример определения блока в SysML вместе с различными его компонентами. Это определение могло бы стать частью диаграммы определений блоков (или набора таких диаграмм).

Сверху показано имя блока. Значения – существенные атрибуты или характеристики РЛС; на рисунке изображено несколько таких атрибутов. В следу-

131

ющем разделе располагаются операции (действия, поведения) блока. В данном случае РЛС выполняет только два типа операций: DetectTarget (обнаружить цель) и StatusCheck (проверка состояния). Конечно, у настоящих РЛС количество операций гораздо больше. На операции, как и на атрибуты блока, могут налагаться ограничения, они перечислены в следующем разделе. Блок можно также определить через его подсистемы или компоненты, которые обычно называются частями. В примере перечислено шесть основных подсистем РЛС. Наконец, в последнем разделе приведены ссылки на другие блоки.

На рисунке 5.16 показано несколько типов ассоциаций блоков. Как и в UML, ассоциации представляют связи между блоками. Простые ассоциации изображаются в виде линий, соединяющих блоки. Если требуется указать направление, то на одном конце линии рисуется стрелка – такие ассоциации называются направленными. Существуют также специальные виды ассоциаций; так, агрегированиеозначает, чтоблоки являются частями одного целого, композиция – один блок входит в другой, зависимость – один блок зависит от другого, а обобщение – блок является частным случаем более общего блока [1].

Рисунок 5.15 – Определение блока в SysML

Рисунок 5.16 – Ассоциации блоков в SysML

132

Диаграмма деятельности. Из всех поведенческих диаграмм UML лишь одна – диаграмма деятельности – подверглась в SysML значительной модификации. Добавлены четыре расширения:

–поток управления дополнен управляющими операторами;

–с помощью непрерывных потоков объектов стало возможно моделировать непрерывные системы;

–с потоками можно ассоциировать вероятности;

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

Благодаря этим расширениям появилась возможность реализовать некоторые существующие приёмы функционального моделирования, например расширенные схемы функциональных потоков (extended functional flow block diagram – EFFBD).

Кроме того, новые расширения позволяют без труда представить дерево функций, например использование функций кофеварки на рисунке 5.17, как показано на рисунке 5.18.

Рисунок 5.17 – Функциональная блок-схема стандартной кофеварки

Эти функции можно изобразить и на более привычной диаграмме деятельности, представленной на рисунке 5.18,б. Для большей наглядности мы не стали включать все11 функций. Общий поток управления показан стрелками и соответствует потоку на рисунке 5.17 (схеме функциональных блоков). Входы и выходы изображены специальными соединителями – стрелками со скрепками (или прямоугольниками, примыкающими к деятельности). С каждым соединителем ассоциирована метка, описывающая, какие объекты передаются через данный интерфейс. Для иллюстрации включен также управляющий оператор – в данном случае он определяет, что

133

передается деятельности «Показать состояние» при различных комбинациях трёх его входов.

а

б

Рисунок 5.18 – Модель кофеварки:

а – дерево функций в SysML; б – диаграмма деятельности в SysML

134

Как и UML, SysML предоставляет системному инженеру и системному архитектору комплект гибких средств моделирования, которые дают возможность представить многиеаспекты, относящиеся к концепции системы. Крометого, SysML позволяет преодолеть некоторые присущие UML проблемы, мешающие использовать более традиционные методы системной инженерии. Пожалуй, самый очевидный пример такого рода – диаграмма требований. После выхода SysML появилось множество коммерческих приложений, помогающих инженеру разрабатывать, анализировать и уточнять концепции системы.

5.4.2 Математическое моделирование систем

Система представляет собой совокупность находящихся в определённой взаимосвязи компонентов, которые принадлежат части реального мира, являющейся объектом исследования. Это определение отражает две содержательные стороны понятия системы – наличие множества компонентов и определённых взаимосвязей между ними, за счёт которых система имеет новые свойства, отсутствующие у входящих в неё компонентов. Свойства системы в равной степени определяются как характеристиками составляющих её компонентов, так и характеристиками взаимосвязей между ними [10].

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

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

выходными параметрами компонентов системы. Чтобы проиллюстрировать вышесказанное, рассмотрим удобный для вычислений случай равенства всех коэффициентов ковариации, образующих ковариационную матрицу R. Значения определителя det R в зависимости от числа компонентов системы n и величин rij приведены в таблице 5.2.

135