Теоретические основы информационных технологий

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

Рубрика Программирование, компьютеры и кибернетика
Вид курс лекций
Язык русский
Дата добавления 05.08.2013
Размер файла 826,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Модель сервера базы данных

Развитием PDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хранимых процедур. В отличие от PDA-модели, определенные для конкретной предметной области информационной системы события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Схематично DBS-модель приведена на рис. 2.5.

Рис. 5.5 Модель сервера базы данных (DBS-модель)

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

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

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

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

Модель сервера приложений

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

Суть AS-модели заключается в переносе прикладного компонента информационной системы на специализированный в отношении повышенных ресурсов по быстродействию дополнительный сервер системы. Схема AS-модели приведена на рис. 5.6

Рис. 5.6. Модель сервера приложений (AS-модель)

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

Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией.

В этом отношении сервер приложений управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют монитором обработки транзакций (Transaction Processing Monitors - TRM), или просто монитором транзакций.

AS-модель, сохраняя сильные стороны DBS-модели, позволяет оптимально построить вычислительную схему информационной системы, однако, как и в случае RDA-модели, повышает трафик сети.

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

Технологии объектного связывания данных

Унификация взаимодействия прикладных компонентов с ядром информационных систем в виде SQL-серверов, наработанная для клиент-серверных систем, позволила выработать аналогичные решения и для интеграции разрозненных локальных баз данных под управлением настольных СУБД в сложные децентрализованные гетерогенные распределенные системы. Такой подход получил название объектного связывания данных.

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

Решение этой задачи основывается на поддержке современными "настольными" СУБД (MS Access, MS FoxPro, dBase и др.) технологии "объектов доступа к данным" - DАО.

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

Технически технология DАО основана на уже упоминавшемся протоколе ODBC, который принят за стандарт доступа не только к данным на SQL-серверах клиент-серверных систем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД.

Непосредственно для доступа к данным на основе протокола ODBC используются специальные программные компоненты, называемые драйверами ODBC (инициализируемые на тех установках, где находятся данные).

Схематично принцип и особенности доступа к внешним базам данных на основе объектного связывания иллюстрируются на рис. 5 7.

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

Рис. 5.7 - Принцип доступа к внешним данным па основе ODBC

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

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

Технически оперирование связанными объектами из внешних баз данных "своего" формата мало отличается от оперирования с данными из текущей базы данных.

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

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

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

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

Аналогичным образом обеспечивается доступ к данным, находящимся в базах данных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE.

При этом доступ может обеспечиваться как непосредственно ядром СУБД, так и специальными дополнительными драйверами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД.

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

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

Технологии реплицирования данных

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

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

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

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

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

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

§ обеспечение согласованного состояния во всех репликах количества и значений общих данных;

§ обеспечение согласованного состояния во всех репликах структуры данных.

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

§ принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

§ принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).

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

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

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

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

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

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

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

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

Тем не менее, развитие и все более широкое распространение распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автоматизированных информационных систем.

Раздел 6. ТЕХНОЛОГИИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

Понятие о компьютерном математическом моделировании

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

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

Математическое моделирование - метод исследования процессов и явлений на их математических моделях.

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

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

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

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

Классификация математических моделей

К классификации математических моделей можно подходить по-разному, положив в основу классификации различные принципы.

1) Классификация моделей по отраслям наук (математические модели в физике, биологии, социологии и т.д.);

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

3) Классификация моделей с точки зрения целей моделирования.

§ дескриптивные (описательные) модели;

§ оптимизационные модели;

§ многокритериальные модели;

§ игровые модели;

§ имитационные модели.

Пример.

1) Моделируя движение кометы, вторгшейся в Солнечную систему, мы описываем (предсказываем) траекторию ее полета, расстояние, на котором она пройдет от Земли и т.д., т.е. ставим чисто описательные цели. У нас нет никаких возможностей повлиять на движение кометы, что-то изменить.

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

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

3) Игровые модели могут иметь отношение не только к детским играм (в том числе и компьютерным), но и к вещам весьма серьезным.

4) Бывает, что модель в большой мере подражает реальному процессу, т.е. имитирует его.

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

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

Этапы, цели и средства компьютерного математического моделирования

Здесь мы рассмотрим процесс компьютерного математического моделирования, включающий численный эксперимент с моделью (рис. 6.1).

Рис. 6.1 - Общая схема процесса компьютерного математического моделирования

Первый этап - определение целей моделирования.

Основные из них таковы:

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

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

3) модель нужна для того, чтобы прогнозировать прямые и косвенные последствия реализации заданных способов и форм воздействия на объект (прогнозирование). Выработка концепции управления объектом - другая возможная цель моделирования. Какой режим полета самолета выбрать для того, чтобы полет был вполне безопасным и экономически наиболее выгодным? Как составить график выполнения сотен видов работ на строительстве большого объекта, чтобы оно закончилось в максимально короткий срок? Множество таких проблем систематически возникает перед экономистами, конструкторами, учеными.

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

Составим список величин, от которых зависит поведение объекта или ход процесса, а также тех величин, которые желательно получить в результате моделирования. Обозначим первые (входные) величины через x1, х2, ..., хn; вторые (выходные) через y1,y2,...,yk.

Символически поведение объекта или процесса можно представить в виде:

yj = Fj(x1, х2, ..., хn) (j =1,2 ,... , k),

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

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

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

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

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

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

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

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

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

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

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

При создании имитационной модели можно также воспользоваться возможностями одного из пакетов математической поддержки (MATHEMATICA, MathCad, MathLab и др).

В настоящее время существуют проблемно-ориентированные имитационные языки, в которых объединяются различные альтернативные подходы, и которые самой своей структурой определяют возможную схему действий разработчика модели. Характерным примером такого рода является имитационный язык СЛАМ II (SLAM - Simulating Language for Alternative Modeling имитационный язык для альтернативного моделирования).

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

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

Моделирования случайных процессов

Моделирование случайных процессов - мощнейшее направление в современном математическом моделировании.

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

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

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

Метод стохастической аппроксимации: рекуррентные алгоритмы решения задач статистического оценивания.

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

Другие методы: вероятностные методы распознавания образов, модели адаптации, обучения и самообучения.

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

Для не слишком требовательного пользователя обычно достаточны возможности датчика (генератора) случайных чисел, встроенного в большинство языков программирования. Так, в языке Паскаль есть функция random, значения которой - случайные числа из диапазона [0, 1]. Ее использованию обычно предшествует использование процедуры randomize, служащей для начальной 'настройки" датчика, т.е. получения при каждом из обращений к датчику разных последовательностей случайных чисел. Для задач, Решение которых требует очень длинных некоррелированных последовательностей, вопрос осложняется и требует нестандартных

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

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

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

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

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

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

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

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

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

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

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

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

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

Раздел 7. ТЕХНОЛОГИИ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Общая характеристика технологии создания программного обеспечения

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

Рассмотрим этапы разработки программ.

Рис.7.1 - Этапы разработки программного обеспечения.

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

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

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

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

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

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

Любой алгоритм обладает следующими важными свойствами: Детерминированностью, массовостью, результатностью и дискретностью.

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

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

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

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

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

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

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

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

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

По своему характеру (причине возникновения) ошибки в программах делятся на синтаксические и логические.

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

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

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

§ программа работает, но не выдает всех запланированных результатов и не выходит на останов (происходит ее "зацикливание");

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

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

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

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

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

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

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

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

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

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

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

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

Современные методы и средства разработки программного обеспечения

Метод нисходящего проектирования (метод пошаговой детализации, метод иерархического проектирования, top-down-подход)

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

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

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

Модульное проектирование

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

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

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

§ по завершении работы модуль должен возвращать управление тому модулю, который его вызывал;

§ модуль должен иметь один вход и выход;

§ модуль должен иметь небольшой размер, обеспечивающий его обозримость.

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

Модульный принцип разработки программ обладает следующими преимуществами:

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

§ появляется возможность создавать и многократно использовать в дальнейшем библиотеки наиболее употребимых программ;

§ упрощается процедура загрузки больших программ в оперативную память, когда требуется ее сегментация;

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

§ обеспечивается более эффективное тестирование программ, проще осуществляются проектирование и последующая отладка.

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

Структурное программирование

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


Подобные документы

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

    курсовая работа [498,9 K], добавлен 29.10.2014

  • Роль структуры управления в информационной системе. Примеры информационных систем. Структура и классификация информационных систем. Информационные технологии. Этапы развития информационных технологий. Виды информационных технологий.

    курсовая работа [578,4 K], добавлен 17.06.2003

  • Теоретические аспекты некоторых областей информационных технологий: программы обработки данных, глобальная сеть Internet. Характеристика методов использования информационных технологий в различных областях бизнеса, опасностей и сложностей в их применении.

    реферат [1,4 M], добавлен 11.04.2010

  • Основные характеристики и принцип новой информационной технологии. Соотношение информационных технологий и информационных систем. Назначение и характеристика процесса накопления данных, состав моделей. Виды базовых информационных технологий, их структура.

    курс лекций [410,5 K], добавлен 28.05.2010

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

    курсовая работа [46,4 K], добавлен 16.09.2011

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

    курсовая работа [147,7 K], добавлен 07.05.2012

  • Информационные технологии, сущность и особенности применения в строительстве. Анализ деятельности информационных технологий, основные направления совершенствования применения информационных технологий, безопасность жизнедеятельности на ООО "Строитель".

    дипломная работа [1,7 M], добавлен 26.09.2010

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

    реферат [17,9 K], добавлен 05.11.2010

  • Условия повышения эффективности управленческого труда. Основные свойства информационных технологий. Системные и инструментальные средства. Классификация информационных технологий по типу информации. Главные тенденции развития информационных технологий.

    реферат [15,4 K], добавлен 01.04.2010

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

    дипломная работа [1,3 M], добавлен 07.02.2009

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.