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

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

Второе требование – простота модели. С одной стороны, простота модели – ее неизбежное свойство: в модели невозможно зафиксировать все многообразие реальной ситуации.

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

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

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

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

вы (рисунок 5.5).

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

Если не вдаваться в подробности оптимизациив рамкахматематических моделей, то интуитивно оптимизация сводится в основном к сокращению числа альтернатив и проверке модели на устойчивость.

Пусть построена модель и найдено оптимальное в ее рамках решение.

116

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

–насколько оптимальное решение чувствительно к ошибкам описания модели, тоесть будут ли малыевозмущения модели приводить кстоль жемалымизменениям оптимального решения (задача анализа устойчивости);

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

вкоторых данное решение еще обладает этими свойствами (задача анализа адекватности).

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

Таким образом, существует определенный дуализм между эффективностью решения и областью его применимости (областью его устойчивости и/или областью адекватности).

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

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

Этап выбора модели (принятия решения). Выбор модели является действием,

придающим всей деятельности целенаправленность. Именно выбор реализует подчиненность всей деятельности определенной цели.

В системном анализе выбор (принятие решения) определяется как действие над множеством альтернатив, в результате которого получается подмножество выбранных альтернатив (как правило, это один вариант, одна альтернатива) [6]. При этом выбор тесно связан с оптимизацией, так как последняя есть не что иное, как выбор оптимальной альтернативы.

117

Каждая ситуация выбора может развертываться в разных вариантах:

–оценка альтернатив для выбора может осуществляться по одному или нескольким критериям, которые в свою очередь могут иметь как количественный, так и качественный характер;

–режим выбора может быть однократным (разовым) или повторяющимся, допускающим обучение на опыте;

–последствия выбора могут быть точно известны (выбор в условиях определенности), иметь вероятностный характер (выбор в условиях риска) или иметь неопределенный исход (выбор в условиях неопределенности);

–ответственность за выбор может быть односторонней (в частном случае индивидуальной, например ответственность проектировщика) или многосторонней (например, когда за принятое решение несут ответственность члены проектной группы). Соответственно различают индивидуальный или групповой, многосторонний выбор;

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

ит.д.

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

–цели, достижение которых определяет успех проекта;

–цели, которыми частично можно пожертвовать для достижения целей первого уровня;

–цели, имеющие характер дополнения.

Влюбом случае выбор (принятие решения) является процессом субъективным,

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

5.3.3 Структурно-функциональное моделирование

Структурно-функциональноемоделирование– видмоделирования, при котором моделями являются схемы, графики, чертежи, диаграммы, таблицы, рисунки и взаимосвязи между ними. Структурно-функциональное моделирование берет свои истоки из теории электрических цепей и радиотехники [8].

Впервые понятие «структурный анализ» было использовано в конце 60-х годов прошлого столетия профессором Массачусетского технологического института Дугласом Россом, который разработал основы современных методов структурнофункционального анализа моделирования сложных систем.

118

Методология структурно-функционального моделирования и анализа сложных систем (SADT) широко использовалась для эффективного решения целого ряда проблем, среди них:

–управление финансами и материально-техническим снабжением крупных

фирм;

–разработка программного обеспечения АСУ телефонными сетями;

–долгосрочное и стратегическое планирование деятельности фирм;

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

Методы структурно-функционального моделирования основаны на следующих принципах:

–разделение систем на части типа «черный ящик»;

–иерархическая организация «черных ящиков»;

–использованиеграфических средств для определения функциональныхсвязей между блоками.

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

Разбиение на «черные ящики» должно удовлетворять следующим критериям:

–каждый «черный ящик» реализует единственную функцию системы;

–функция каждого «черного ящика» является легко понимаемой независимо от сложности ее внутренней структуры;

–связь между «черными ящиками» вводится только при наличии связи между соответствующими функциями системы;

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

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

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

119

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

5.4.1 Языки системного моделирования

Рассмотрим два языка для реализации объектно-ориентированных моделей. Во всех методиках описания архитектуры системы для отображения различных

системных аспектов, ракурсов и представлений применяются модели. Традиционные модели, в том числе структурные схемы, основаны на использовании нисходящей декомпозиции системы. Обычно такие методы базируются на функциональных представлениях и предполагают формирование иерархии моделей со все большей степенью детализации. В 1970-х годах, когда программная инженерия развивалась ускоренными темпами, появилась формальная методика моделирования, получившая название «структурный анализ и проектирование» (structured analysis and design – SAAD)4. Этот термин применялся к любым, а не только к программным системам [9].

Модели, которые использовались на протяжении нескольких десятилетий, во многом напоминают конструкции SAAD, поэтому для них было предложено собирательное название традиционные иерархические методы или просто

традиционное системное моделирование.

Появление SAAD подтолкнуло разработку новых языков моделирования, основанных на принципах объектно-ориентированного анализа и проектирования

(object-oriented analysis and design – OOAD). В этой методике при анализе и проек-

тировании главным образом используется подход, предполагающий восхождение от нижних к верхним уровням системной иерархии, и упор делается на сущностях или объектах, а не на функциях, хотя те и другие тесно связаны. В 1990-х годах был формализован новый язык моделирования, вобравший в себя принципы и приёмы

OOAD: унифицированный языкмоделирования(UnifiedModeling Language– UML).

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

При разработке сложной системы важно создавать высокоуровневые модели её структуры и поведения, чтобы понять, как может быть сконфигурирована система, отвечающая предъявляемым требованиям. При разработке методологии OOAD несколько известных учёных-практиков независимо создали подобные модели. В середине 1990-х годов трое из них (Гради Буч, Джеймс Рамбо и Ивар Якобсон) предложили единую терминологию для моделирования, которую они назвали UML. Сообщество разработчиков ПО приняло этот язык в качестве стандарта, после чего он стал широко использоваться в коммерческих и государственных проектах. UML поддерживается развитыми инструментами, разрабатываемыми несколькими ведущими производителями инструментального ПО.

UML предлагает аналитикам и специалистам по проектированию 13 разных способов схематического представления характеристик системы. Среди них

4 В нашей стране чаще используется другое название, а именно методология структур-

ного анализа и проектирования (Structured Analysis and Design Technique – SADT).

120

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

Рисунок 5.6 – Модели в UML

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

На диаграммах классов (class diagram) показывается набор классов, связей между ними и их интерфейсов.

На диаграммах объектов (object diagram) показываются экземпляры классов (объекты) системы и связи между ними.

Диаграммы компонентов (component diagram) обычно используется для пояснения структуры физических объектов и связей между ними.

Диаграмма развертывания (deployment diagram) даёт статическое представление физических компонентов системы.

На диаграмме композитной/составной структуры(composite structure diagram)

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

На диаграммах пакетов (package diagram) представляется иерархия компонентов.

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

На диаграммах вариантов использования (use case diagram) показываются отношения между вариантами использования, представляющими функции системы, которые отвечают за взаимодействия с внешними сущностями (акторами).

На диаграммах последовательностей (sequence diagrams) отражаются хроно-

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

На диаграммах состояний (state machinediagrams) моделируются события перехода состояний и действия, которые изменяют состояние системы.

Диаграммы деятельности (activity diagrams) представляют собой схемы различных действий в некоторой части системы и потоки управления между ними.

На диаграммах коммуникаций (communication diagrams) определяются связи между объектами с акцентом на их взаимодействия.

121

Диаграммы обзора взаимодействий (interaction overviewdiagrams) – это комбинация диаграмм последовательностей и деятельности.

На временных диаграммах (timing diagrams) представляются взаимодействия между объектами вместе с хронометрической информацией.

Диаграммы классов в UML приблизительно соответствуют диаграммам «сущность–связь» в структурном анализе, а диаграммы состояний – диаграммам перехода состояний. Прочие диаграммы, в особенности диаграммы деятельности, – это различные виды схем функциональныхпотоков. Новый язык был быстро принят на вооружение сообществом системных инженеров как стандарт де-факто для представления программных концепций и преимущественно программных систем. Хотя истоки языка лежат в мире программного обеспечения, в последнее время он успешно применялся для разработки систем, включающих как программные, так и аппаратные средства.

Развитие языка UML направляется всемирным консорциумом Object Management Group (OMG). UML продолжает развиваться, выходят новые версии, увеличивается сложность. Вместо того чтобы подробно рассказывать обо всех диаграммах, приведем несколько примеров поведенческих диаграмм – вариантов использования, деятельности и последовательности, и одну структурную – диаграмму классов.

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

На рисунке 5.7 моделируется взаимодействие действующего лица, или субъекта действия, – актора («библиотекарь»), с одним вариантом использования (представлен овалом), который ведет к выполнению подчинённого действия (отдельный вариант использования), тогда как три других варианта взаимодействуют со вторым (внешним) актором. Стрелки показывают, кто инициирует вариант использования, а не направление потока информации. Например, актор «библиотекарь» может инициировать вариант использования «управление абонементом». Тот же вариант может быть инициирован вариантом использования «вернуть книгу».

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

–название;

–краткое описание;

–список акторов;

–начальные условия (предусловия), описывающие состояние окружения до начала варианта использования;

–конечные условия (поступления), описывающие состояние окружения после завершения варианта использования;

–последовательность событий – список событий или действий, происходящих

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

122

Окончание таблицы 5.1

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

–действие (action) – элементарный осуществимый шаг в рамках деятельности (прямоугольник со скруглёнными углами);

–дуга деятельности (activity edge) – линия, соединяющая действия, а также действия и узлы (со стрелкой). Дуги деятельности бывают двух типов: потоки объектов и потоки управления;

124

–поток объектов (object flow) – дуга деятельности, по которой перемещаются объекты (или символические обозначения объектов);

–поток управления (control flow) – дуга деятельности, которая представляет направление управления (кроме того, по ней перемещаются маркеры управления);

–соединитель, или скрепка (pin) – связующее звено между параметрами действия и потоком (прямоугольник, соединённый с действием и потоком). Соединитель принимает явные входы или порождает явные выходы действия;

–начальный узел (initial node) – начальная точка потока управления (сплошной

круг);

–конечный узел (final node) – конечная точка потока управления (сплошной круг внутри окржуности большего радиуса);

–узел принятия решения (decision node) – точка ветвления потока, каждая ветвь содержит условие, при котором она выбирается (ромб);

–узел слияния (merge node) – точка, в которой несколько потоков объединяются

водин (ромб);

–узел разделения (fork node) – точка, в которой один поток разветвляется на несколько параллельно выполняемых (жирная линия);

–узел соединения (join node) – точка, в которой несколько параллельно выполняемых потоков синхронизируются и соединяются в один поток (жирная линия).

На рисунке 5.8 показана простая диаграмма деятельности для примера с библиотечной системой, аналогичная схеме функциональных потоков. Здесь одна деятельность разветвляется на две, соответствующие двум логическим путям: выдача и возврат книги.

Рисунок 5.8 – UML-диаграмма деятельности

125