Выбор способа моделирования и оценки качества модели

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

Для нашего объекта исключительно подходит такой способ моделирования как компьютерное моделирование с системе Matlab.

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

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

Разработка модели объекта исследования.

2.1 Математическая модель и аппарат для построения модели “Объекта"

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

MATLAB (сокращение от англ. «MatrixLaboratory», в русском языке произносится как Матлаб) — пакет прикладных программ для решения задач технических вычислений и одноимённый язык программирования, используемый в этом пакете. Пакет используют более миллиона инженерных и научных работников, он работает на большинстве современных операционных систем, включая Linux, Mac OS, Solaris .

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

Программы, написанные на MATLAB, бывают двух типов — функции и скрипты. Функции имеют входные и выходные аргументы, а также собственное рабочее пространство для хранения промежуточных результатов вычислений и переменных. Скрипты же используют общее рабочее пространство. Как скрипты, так и функции сохраняются в виде текстовых файлов и компилируются в машинный код динамически. Существует также возможность сохранять так называемые pre-parsed программы — функции и скрипты, обработанные в вид, удобный для машинного исполнения. В общем случае такие программы выполняются быстрее обычных, особенно если функция содержит команды построения графиков.

Основной особенностью языка MATLAB являются его широкие возможности по работе с матрицами, которые создатели языка выразили в лозунге «думай векторно»

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

Процесс построения и    изучения математических моделей

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

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

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

Говоря конкретнее, нужно установить  математическую связь между всеми данными задачи.

Задач в мире бесконечное количество. Поэтому предложить четкую пошаговую инструкции по составлению математическоймодели любой задачи – невозможно.

Разработка модели

2.2.1 Упрощение и ограничения модели

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

В обоих случаях возникает необходимость упрощения математических 1 моделей объекта.

 Наиболее распространенными являются следующие методы упрощения моделей:

 1) расчленение сложной системы на ряд более простых подсистем;

2) выделение существенных свойств и воздействий и учет остальных в параметрической форме (метод макро моделирования);

3)линеаризация нелинейных процессов в некоторой области изменения переменных;

4)приведение систем с распределенными параметрами к системам с распределенными параметрами (введение более жестких предположений ограничений);

5)пренебрежение динамическими свойствами процессов.

Алгоритм

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

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

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

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

Выбор ПО для построения модели

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

Программа

Методика оценки качества

1. Оценка качества модели является завершающим этапом ее разработки и преследует две цели:

1) проверить соответствие модели ее предназначению (целямисследования),

2) оценить достоверность и статистические характеристики результатов, получаемых при проведении модельных экспериментов.

При аналитическом моделировании достоверность результатов

к определяется двумя основными факторами:

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

2) методической ошибкой, присущей данному математическому l методу.

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

• моделирование случайных факторов, основанное на использовании датчиков СЧ, которые могут вносить «искажения» в поведение модели;

наличие нестационарного режима работы модели;

•наличие модели рабочей нагрузки, качество которой зависит, в свою очередь, от тех же факторов.

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

•    адекватность;

•    устойчивость;

•    чувствительность.

Оценка адекватности модели. В общем случае под адекватностью понимают степень соответствия модели тому реальному явлению или объект, для описания которого она строится.

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

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

•    по средним значениям откликов модели и системы;

*    по дисперсиям отклонений откликов модели от среднего значения откликов системы;

•    по максимальному значению относительных отклонений откликов модели от откликов системы.

Оценка устойчивости модели. Устойчивость модели - это ее способность сохранять адекватность при исследовании эффективности системы на всем возможном диапазоне рабочей нагрузки, а также при внесении изменений в конфигурацию системы. Разработчик вынужден прибегать к методам «для данного случая», частичным тестам и здравому смыслу. Часто бывает полезна апостериорная проверка. Она состоит в сравнении результатов моделирования и результатов измерений на системе после внесения в нее изменений. Если результаты моделирования приемлемы, уверенность в устойчивости модели возрастает.

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

Оценка чувствительности модели. Достаточно часто возникает задача

Оцениваниячувствительностимоделикизменениюпараметроврабочей

нагрузки и внутренних параметров самой системы.

Тесты

«Борьба за качество» программ может вестись двумя путями. Первый 1 путь «прост»: собрать команду хороших программистов с опытом участия в аналогичных проектах, дать им хорошо поставленную задачу, хорошие инструменты, создать хорошие условия работы. С большой вероятностьюможно ожидать, что удастся разработать программную систему с хорошим качеством.

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

В простейшем варианте набор этапов жизненного цикла таков:

•    анализ требований;

•    проектирование (предварительное и детальное);

•    кодирование и отладка ("программирование");

•    тестирование;

•    эксплуатация и сопровождение.

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

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

В конце 80-х годов была предложена так называемая спиральная модель, был развит и проверен на практике метод итеративной и инкрементальной разработки (IterativeandIncrementalDevelopment, IID). В  спиральной модели были учтены проблемы водопадной модели. Главный упор в спиральной модели делается на итеративности процесса. Описаны опыты использования IID с длиной итерации всего в полдня. Каждая итерация завершается выдачей новой версии программного обеспечения. На каждой версии уточняются (и, возможно, меняются) требования к целевой системе и принимаются меры к тому, чтобы удовлетворить и новые требования. В целом RationalUnifiedProcess (RUP) также следует этой модели.

Позволило ли это решить проблему качества? Лишь в некоторой степени.

Проблема повышения качества программного обеспечения в целом и повышения качества тестирования привлекает все большее внимание; в университетах вводят специальные дисциплины по тестированию и обеспечению качества, готовят узких специалистов по тестированию и инженеров по обеспечению качества. Однако по-прежнему ошибки обходятся только в США от 20 до 60 млрд. долл. ежегодно. При этом примерно 60% убытков ложится на плечи конечных пользователей.

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

Вместе с тем, ситуация не безнадежна. Исследование, проведенное Национальным институтом стандартов и технологии США, показало, что размер убытков, связанных со сбоями в программном обеспечении, можно уменьшить примерно на треть, если вложить дополнительные усилия в инфраструктуру тестирования, в частности, в разработку инструментов тестирования.

Каково же направление главного удара? Что предлагают «наилучшие практики»?

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

Впоследниегодывсвязи с появлением методов, которые принято обозначать эпитетом agile («шустрый», «проворный») предлагаются и используются новые конструктивные методы раннего обнаружения ошибок. Скажем, современные модели, такие как MicrosoftSolutionsFramework (MSF)

Рекомендации к разработке текстов :

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

•    если же в требования вносятся изменения, то тесты должны меняться максимально оперативное

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

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

В новых моделях жизненного цикла тестирование как бы растворяется других фазах разработки. Так, MSF не содержит фазы тестирования тесты пишутся и используются всегда!

Итак, различные работы в процессе производства программ должны быть хорошо интегрированы с работами по тестированию. Соответственно, инструменты тестирования должны быть хорошо интегрированы со многими другими инструментами разработки. Из крупных производителей инструментов разработки программ, первыми это поняли компании Telelogic (набор инструментов для проектирования, моделирования, реализации и тестирования телекоммуникационного ПО, базирующийся на нотация: SDL/MSC/TTCN) и RationalSoftware (аналогичный набор, преимущественно базирующийся на нотации UML). Следующий шаг сделала компания ЮМ, начав интеграцию возможностей инструментов от Rational в среду разработки программ Eclipse.

Тезис ХР — «Пиши тест перед реализацией» — хорош как лозунг, но в реальности столь же неконструктивен. Для крупных программных комплексов приходится разрабатывать тесты различного назначения: тесты модулей, интеграционные или компонентные тесты, системные тесты.