Средства моделирования систем. Обеспечение моделирования

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

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

ЭВМ – техническое средство ИМ. Имитационная система, реализуемая на ЭВМ, позволяет исследо-вать исходную модель в виде совокупности от-дельных блоков. Обычно блоки разделяют на три группы:

-блоки, описывающие процесс функционирования системы

-блоки, отображающие внешнюю среду и ее воздействие на процесс

-вспомогательные блоки, обеспечивающие взаимодействие блоков и дополнительные функции

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

Математическое обеспечение включает совокуп-ность математических соотношений, алгоритмов, описывающих поведение реального объекта и обеспечивающих работу системы.

Программное обеспечение – это совокупность программ по планированию, обработке результа-тов. Программное обеспечение синхронизирует процессы в системе.

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

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

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

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

1. Назначение внешнего описания программного средства

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

Внешнее описание ПС = определение требований

+ спецификация качества ПС

+ функциональная спецификация ПС

где

функциональная спецификация ПС – Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции.

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

2.Определение требований к программному средству.

Известны три способа разработки определения требований к ПС:

• управляемая пользователем разработка,

• контролируемая пользователем разработка,

• независимая от пользователя разработка.

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

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

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

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