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

Рис 1.9 Сэндвич системной инженерии.

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

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

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

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

На рис. 1.10 показаны взаимосвязанные роли, которые играют разработка требований и системное моделирование.

Рис 1.10 Требования и моделирование.

На определенном уровне моделирование помогает системному инженеру в анализе требований для:.

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

• анализа системы с целью убедиться в наличии желаемых системных свойств (emergent properties) и, что также немаловажно, - в отсутствии нежелательных свойств;.

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

Природа моделей на разных уровнях различна. На верхнем уровне используются «пользовательские сценарии» (stakeholder scenarios) для получения пользовательских требований (stakeholder requirements).

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

-диаграммы: диаграммы классов (class diagrams), диаграммы последовательности сообщений (message sequence charts) и диаграммы состояний (state charts). (Более подробно данная техника моделирования будет рассмотрена в Главе 3.).

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

Как следует из приведенных примеров, для различных системы применяются различные типы моделей. Тип модели может меняться от приложения к приложению и зависеть от конкретной природы системы. Моделирование расписаний применяется для проектирования железнодорожных систем, но для разработки воздушных судов оно вряд ли применимо, поскольку в данном случае более уместно использование аэродинамического моделирования. (Аэродинамика, несомненно, важна также и для высокоскоростных поездов). Для моделирования систем передачи данных (и голоса) используются диаграммы последовательности сообщений, а для моделирования систем, имеющих сложную структуру данных, применяются модели, содержащие диаграммы «сущность-связь» (entityrelationship diagrams).

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

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