Экзаменационный билет № 21

1. Интерполяция функций. Интерполяционный полином Лагранжа.

2. Проект. Классификация проектов.

3. Архитектура БД. Физическая и логическая независимость.

4. Понятия проекта и проектирования ИС

5. Факторы выбора инструментальных средств моделирования. Механизмы формирования системного времени.

6. Инкапсуляция пакетов в стеке TCP/IP.

1)Интерполяция функций. Интерполяционный полином Лагранжа.

2)Проект. Классификация проектов.

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

Проекты можно классифицировать по различным признакам. Отметим основные из них.

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

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

Масштаб проекта определяется размером бюджета и числом участников: мелкие проекты, малые проекты, средние проекты, крупные проекты. Можно рассматривать масштаб проекта в более конкретной форме – отраслевые, корпоративные, ведомственные, проекты предприятия.

3)Архитектура БД. Физическая и логическая независимость.

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

Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 1.2:

Рис. 1.2. Трехуровневая модель системы управления базой данных, предложенная ANSI

1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.

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

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных

4)Понятия проекта и проектирования ИС

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

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

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

Проектирование ИС охватывает три основные области:

ü проектирование объектов данных, которые будут реализованы в базе данных;

ü проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

o требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

o требуемой пропускной способности системы;

o требуемого времени реакции системы на запрос;

o безотказной работы системы;

o необходимого уровня безопасности;

o простоты эксплуатации и поддержки системы.

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

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

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

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

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

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

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

Конечными продуктами этапа проектирования являются:

o схема базы данных (на основании ER-модели, разработанной на этапе анализа);

o набор спецификаций модулей системы (они строятся на базе моделей функций).

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

Этап проектирования завершается разработкой технического проекта ИС.

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

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

o обнаружение отказов модуля (жестких сбоев);

o соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

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

5)Факторы выбора инструментальных средств моделирования. Механизмы формирования системного времени.

1) Факторы выбора инструментальных средств моделирования:

В какой форме будет описываться объект исследования: непрерывная, дискретная система или смешанный вариант.

· Проблемно-ориентированная среда (ARENA, ARIS) или универсальная система (GPSS) На выбор той или иной системы влияет выполнение следующих условий: 1) Наличие практического опыта работы с конкретным инструментальным средством, в том числе и наличие обученного персонала. Все современные системы достаточно сложны (особенно в части средств организации эксперимента и анализа). 2) Стоимость лицензии и стоимость разработки. Их соотношение со средствами, выделенными на проект. Современные проблемно-ориентированные системы моделирования очень дороги, по сравнению с просто языками моделирования. 3) Размерность создаваемой модели (несложный объект, учебные задачи и т.д.). Современные средства моделирования достаточно функциональны. Поэтому при небольшой размерности целесообразнее ориентироваться на более простую систему (GPSS/W), даже если она не очень вписывается в предметную область. 4) Предметная область объекта исследования. Возможность или ее отсутствие выбрать конкретную проблемно-ориентированную систему.

· Внутренние факторы: а) Виды возможных статистических испытаний. Хотя современные системы моделирования в этом отношении достаточно функциональны, тем не менее, специфика все-таки имеется. Поэтому, если исследуемая система требует разнообразных средств анализа и испытаний необходимо учитывать этот фактор при выборе конкретной системы моделирования. б) Степень трудности изменения структуры модели. Если структура моделируемой системы неочевидна или подвержена изменениям (новый объект, предпроектное обследование), то этот фактор, безусловно, является очень важным. в) Способ организации учета времени и происходящих действий.

2) Определение механизма регламентации событий и процессов.

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

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

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

Метод фиксированных шагов:

ü События появляются регулярно и распределены во времени равномерно.

ü В течение цикла моделирования T появляется очень много событий, причем математическое ожидание продолжительности событий невелико.

ü Точная природа существенных событий не ясна. Например, на начальном этапе имитационного исследования.

Метод переменных интервалов времени:

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

ü Не требует определения величины времени приращения

ü Может эффективно использоваться при неравномерном распределении событий во времени и (или) большой величине математического ожидания их продолжительности.

6)Инкапсуляция пакетов в стеке TCP/IP.

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

Пример инкапсуляции пакетов в стеке TCP

Особенности TCP/IP:

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

n независимость от физической среды передачи;

n система уникальной адресации;

n стандартизованные протоколы высокого уровня для распространенных пользовательских сервисов.