Вопрос 3. Метод Монте-Карло и проверка статистических гипотез. Использование законов распределения случайных величин при имитации экономических процессов.

Использование современных имитационных моделей основано, в основном, на идее метода Монте-Карло.

Существует два типа имитационных моделей.

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

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

Если при классификации использовать степень неопределенности, то модели можно разбить на:

1. детерминированные

2. стохастические

3. смешанные.

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

Зарождение метода связано с работой фон Неймана и Улана в конце 1940-х гг., когда они ввели для него название «Монте-Карло» и применили его к решению некоторых задач экранирования ядерных излучений.

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

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

- случайные моменты времени, в которые поступают заказы на фирму

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

- внешние воздействия

- оплата банковских кредитов

- поступление средств от заказчика

- ошибки измерения

БИЛЕТ № 13

Информационный подход к оценке управленческих структур. Понятие системной, собственной и взаимной (внутренней) сложности системы. Оценки степени централизации/децентрализации системы α и β, их характеристики и использование в сравнительной оценке оргструктур.

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

где N – число оцениваемых элементов системы управления.

Для оценки вариантов организационную структуру можно рассматривать с точки зрения ее сложности как системы. С этой точки зрения можно выделить три вида сложности: системную - С_С, собственную - С_О и взаимную - С_В сложности системы, которые между собой связаны формулой С_С=С_о+С_В.

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

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

С_о = log₂n.

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

Системная сложность С_С – здесь вкладывается смысл учета тех узлов, которые выполняют функциональные назначения системы, т.е. определяется количеством листьев, нижним уровнем иерархии, который приводит в жизнь начальственные указания, реализуя системные функции, «пахарями», С_С вычисляется по той же формуле,

С_с = log₂n.

только n = количеству листьев.

Взаимная или внутренняя сложность С_В характеризует степень взаимосвязи элементов в системе (т. е. сложность ее устройства, схемы, структуры).

С_В =С_С –С_о.

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

Естественно, что абсолютные величины количества информации (биты) не позволяют сравнивать системы между собой. В этом случае вводятся относительные характеристики – нормированные величины, благодаря которым можно сравнивать отличающиеся друг от друга разные структуры. Такими нормированными величинами в информационной теории систем являются два взаимосвязанных коэффициента a и b. Их значения нормированыпо собственной сложности.Каждая система имеет свою собственную сложность. Относя к этой собственной сложности взаимную и системную сложность, мы получаем возможность сравнивать между собой системы. Разделив члены выражения С_С =С_о+С_В

на С_О, получим две важные относительные сопряженные оценки a и b: a=-С_В/С_О, b=С_С/С_О, причем, b=1—a

Первая из них a=-С_В/С_О характеризует степень целостности, связности, взаимозависимости элементов системы; для организационных систем может быть интерпретирована как характеристика степени централизации управления. Вторая b=С_С/С_О - самостоятельность, автономность частей в целом, степень использования возможностей элементов. Для организационных систем b удобно называть коэффициентом использования элементов в системе.

Знак минус в выражении для a введен для того, чтобы a было положительным, поскольку С_В в устойчивых системах, для которых характерно С_О>С_С, имеет отрицательный знак. Связанное (остающееся как бы внутри системы) содержание С_В характеризует работу системы на себя, а не для выполнения стоящей перед ней цели (чем и объясняется отрицательный знак С_В).

Используя соотношения a=-С_В/С_О и b =С_С/С_О, легко видеть, что если элементы системы независимы друг от друга, то С_В= 0 и a= 0, зато С_С=С_О и b = 1; напротив, если элементы полностью интегрированы в целом, то С_В=-С_о и a= 1, но зато С_С= 0 и b= 0 (нет исполнителей).

Основные понятия и классификация CASE- технологий. Архитектура CASE- средства. Классификация современных CASE-средств.

Ответ:

Больш. CASE-систем ориент-но на авт-цию проек-я прогр. обесп-я и основано на методологиях структ. или объектно-ориент-го проек-я и прогр-я. Наиб. потребность в исп-и CASE-систем - на нач. этапах разр-ки, - на этапах анализа и спецификации требований к ЭИС. CASE-тех-я вкл-ет методы, с помощью кот. на основе граф. нота­ции строятся диагр-ы, поддерж-ые инструм-ой средой. Метод-я опред-ет шаги и этапность реал-ции про­екта, а также правила исп-ия методов, с пом. К-ых разр-ся проект. Метод - это проце-ра или техника генерации описаний ком­п-ов ЭИС (н-р, проект-ие потоков и структур данных). Нотация – отоб-е стр-ры с-ы, эл-тов дан­ных, этапов обр-ки с пом. специальных граф. сим­волов диаграмм, а также описание проекта с-ы на формаль­ных и естественных языках. Ядром с-ы явл-ся БД проекта – репозиторий. Граф. редактор диаграмм предназначен для отобр-я в граф. виде в заданной нотации проект-ой ЭИС. Верификатор диаграмм служит для контроля прав-ти построения диаграмм в заданной методологии проек-я. Документатор проекта позв-ет получать инф-ю о состоянии проекта в виде различ. отчетов. Администратор проекта представляет собой инстр-ты, необх-ые для вып-ия: инициализации проекта; задания нач. пар-ров проекта; Сервис - набор сист. утилит по об­служ-ю репозитория. Важное значение приобретают CASE-с-ы, ориент-ые на про­ект-е и генерацию баз данных и польз-ких интер­фейсов. Генерация интерфейсов с БД и возможность пре­образования между различн. концепт. схемами и моделями данных увелич-ет мобильность прикладных систем при переходе в др. операционные сре­ды. В общ. случае при выборе CASE-с-ы необх. учитывать след. аспекты: Наличие базы проектных данных, архива или словаря, Интерфейсы с другими CASE-системами, Многопольз. режим, Расширение новыми методологиями, Наличие граф. средств поддержки методологий проек-я, обесп-е качества проектной документации, мониторинга выполнения проекта. CASE-с-ы класс-ся: по поддерживаемым методологиям проек-я: функц-ориент-ые, объектно-ориент-ые и комплексно-ориент-ые; по поддерживаемым граф. нотациям построения диаграмм: с фикс. нотацией, с отдельными нотациями и наиболее распр-ми нотациями; по степени интегрированности: tools, toolkit и workbench; по типу и архитектуре выч. техники: ориент-ые на ПЭВМ, ориент-ые на локальную выч. сеть, ориент-ые на глоб. выч. сетьи смешанного типа; по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориент-ые на режим реального времени разработки проекта, ориент-ые на режим объединения подпроектов; по типу операционной с-ы (ОС)..

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

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

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

Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

Преимущества CASE-технологии:

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

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

• снижение времени создания системы;

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

• возможность коллективной разработки ЭИС в режиме реального времени.

Архитектура CASE-технологии:

Ядром системы является база данных проекта - репозиторий. Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Репозиторий содержит информацию об объектах проектируемой ИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним.

Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ИС. Он создает элементы диаграмм и взаимосвязи между ними; задает описания элементов диаграмм; редактирует элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ИС. Он выполняет: мониторинг правильности построения диаграмм; диагностику и выдачу сообщений об ошибках;

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

Администратор проекта – это инструменты, необходимые для выполнения: инициализации проекта; задания начальных параметров проекта; назначения и изменения прав доступа к элементам проекта;

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

Дата добавления: 2015-12-08