Билет 9

Простейшие формулы ЧИ

Если в таблице всего два узла, то  естественно искомую площадь приближенно оценить так: (х1 – х0)*у0.     Или так: (х1 – х0)*у1. Это  формулы «прямоугольника». А если так: (х1–х0)*0,5(у0+y1), то это формула  трапеции. Если есть три равноотстоящих узла, то проводим через них параболу (формула Симпсона):  (1/3) (x1–x0)(y0+4y1+y2) .

2. Методология и технология создания ИС. Основные задачи и требования.

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

 Основными задачами, решение которых должна обеспечивать методология создания КИС, являются следующие:

· обеспечение создания ИС, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов;

· гарантия создания ИС с заданными параметрами в заданный срок в рамках оговоренного бюджета;

· простота сопровождения, модификации и расширения системы;

· возможность использования в создаваемой ИС разработанных ранее средств информационных технологий (ПО, БД, компьютеров, телекоммуникаций).

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

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

Технологию проектирования можно рассматривать как совокупность трех составляющих:

1. заданной последовательности выполнения ТО проектирования;

2. критериев и правил для оценки результатов выполнения ТО;

3. графических и текстовых средств для описания проектируемой ИС.

Каждая ТО должна обеспечиваться следующими материальными и информационными ресурсами:

· данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

· методическими материалами, инструкциями, нормативами и стандартами;

· программными и техническими средствами;

· исполнителями .

    Результаты ТО должны представляться в стандартном виде .

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

1. поддержка полного ЖЦ ИС;

2. обеспечение достижения целей разработки ИС с заданным качеством и в заданные сроки;

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

4. обеспечение минимального времени получения работоспособной ИС;

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

6. обеспечение независимости выполняемых проектных решений от средств реализации (СУБД, ОС, языка и системы программирования).

3. Ср едства тестирования

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

Одно из наиболее развитых средств тестирования QA (новое название - Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.

Основными компонентами QA являются:

QA Partner - среда для разработки, компиляции и выполнения тестов;

QA Planner - модуль для разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;

Agent - модуль, поддерживающий работу в сети.

Процесс тестирования состоит из следующих этапов:

создание плана тестирования;

связывание плана с тестами;

пометка и выполнение тестов;

получение отчетов о тестировании и управление результатами.

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

Для связывания плана с тестами необходимо создать управляющие предложения (скрипты) на специальном языке 4Test и тесты, которые выполняют требования плана, и связать компоненты любым способом. Для избежания перегруженности тестов используют управление тестовыми данными.

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

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

Комплекс QA занимает на жестком диске не более 21МВ. Поддерживаемые платформы: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris.

4.Алгоритм разрешения имен в службе DNS.

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

Сервис DNS строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера DNS-сервер.  

Например, когда мы хотим обратиться к серверу ipm.kstu.ru, ваш браузер, используя resolver, поступает следующим образом:

1.  ищет запись ipm.kstu.ru в файле hosts, если не находит, то,
2.  посылает запрос на известный DNS-кэширующий сервер (как правило, локальный), если на этом сервере  запись не найдена, то,
3.  сервер DNS-кэширующий обращается к DNS-ROOT серверу с запросом адреса DNS сервера отвечающего за домен первого уровня ru, если получает адрес, то,
4.  сервер DNS-кэширующий обращается к DNS серверу, отвечающего за домен первого уровня ru, с запросом адреса DNS сервера отвечающего за домен второго уровня kstu.ru, если получает адрес, то,
5.  сервер DNS-кэширующий посылает запрос на DNS сервер, отвечающий за домен второго уровня kstu.ru, если получает адрес, то,
6.  сервер DNS-кэширующий адрес кэширует и передает клиенту
7.  клиент обращается по IP адресу - 195.208.44.20

На схеме это выглядит так:

5.Области применения имитационного моделирования. Основные преимущества и недостатки.

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

1) Основным достоинством имитационного моделирования является универсальность подхода при моделировании систем различной сложности и с различной степенью детализации.

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

2) Целесообразность применения. Имитационные модели представляют собой

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

1.  Не существует законченной математической постановки задачи, либо еще не разработаны аналитические методы решения сформулированной математической модели;
2.  Аналитические методы имеются, но математические процедуры столь сложны и трудоемки, что имитационное моделирование дает более простой способ решения задачи (большинство проблем управления социо техническими системами попадает в 1 и 2 категории);
3.  Аналитические решения существуют, но их реализация невозможна вследствие недостаточной математической подготовки  имеющегося персонала. В этом случае следует сопоставить затраты на проектирование, испытания и работу на имитационной модели с затратами, связанными с приглашением специалистов со стороны.
4.  Кроме оценки определенных параметров, желательно осуществить на имитационной модели наблюдение за ходом процесса в течение некоторого времени (это возможно только на имитационной модели);
5.  Имитационное моделирование может оказаться единственной возможностью вследствие трудностей постановки экспериментов и наблюдения явлений в реальных условиях;
6.  Для долговременного действия систем или процессов может понадобиться сжатие временной шкалы. Имитационное моделирование дает возможность полностью контролировать время изучения системы, поскольку явление может быть замедлено или ускорено по желанию.

3) Недостатки:

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

4) Область применения имитационного моделирования

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

6.Сетевая модель данных.

Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of DataSystem Languages), которая определила базовые понятия модели и формальный язык описания.

Базовыми объектами модели являются:

элемент данных;

агрегат данных;

запись;

набор данных,

Элемент данных — то же, что и в иерархической модели, то есть минимальная информационная единица, доступная пользователю с использованием СУБД.

Агрегат данных соответствует следующему уровню обобщения в модели. В модели определены агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа. Агрегат данных имеет имя, и в системе допустимо обращение к агрегату по имени. Агрегат типа вектор соответствует линейному набору элементов данных.

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

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

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

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