Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

ответы на госы по 5 дисциплине

.docx
Скачиваний:
63
Добавлен:
05.06.2015
Размер:
467.33 Кб
Скачать

1

  1. КЛИЕНТЫ УДАЛЕННОГО ДОСТУПА И ПОСТРОЕНИЕ ЗАПРОСОВ К СУБД.

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

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

Существуют модели:

- Клиент-сервер;

- Файл-сервер;

- Сервер базы данных;

- Сервер приложений.

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

В сети один и тот же компьютер может выполнять и роль клиента, и роль сервера. Например, в АИС, включающей персональные компьютеры, большую ЭВМ и мини-компьютер под управлением UNIX, последний может выступать как в качестве сервера БД, обслуживая запросы от клиентов — персональных компьютеров, так и в качестве клиента, направляя запросы большой ЭВМ.

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

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

Недостаток модели: интенсивный трафик.

Модель сервер базы данных. Модель реализована в реляционных СУБД. В основе модели-механизм хранимых процедур –средство программирования SQL –сервера. Прикладной ком понент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД.

Достоинство модели-возможность снижения трафика.

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

2

  1. ОБЕСПЕЧЕНИЕ ДОСТОВЕРНОСТИ ИНФОРМАЦИИ В ПРОЦЕССЕ ХРАНЕНИЯ И ОБРАБОТКИ

Для обеспечения достоверности применяется технология RAID-массивы.

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

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

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

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

Сервер SQL имеет три модели восстановления БД; каждая из них сохраняет данные в момент ошибки сервера, различие только в том, как SQL Server восстанавливает данные, как хранит и сколько требуется затрат производительности в момент ошибки диска.

Полная модель восстановления. Модель полного восстановления следует использовать, когда необходимо полное восстановление с поврежденного носителя. Эта модель использует копию БД и всей информации журнала для восстановления БД. Сервер SQL журнализирует (см. гл.1) все изменения в БД, включая массивные операции и создание индексов. Если журнал транзакций не испорчен, то можно восстановить все данные, исключая транзакции, которые были активны в момент ошибки.

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

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

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

Рассмотрим методы резервирования:

Полное резервирование БД. При использовании БД в основном только для чтения полное резервирование может быть наилучшим решением для предотвращения потери данных. Во время выполнения полного резервного копирования SQL Server:

  • резервирует любую активность, которая происходит во время резервирования;

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

Дифференцированное резервирование БД выполняется для сокращения времени, необходимого для восстановления часто изменяемой БД. Метод рекомендуется использовать в случае, если выполнено полное резервирование. При дифференцированном резервировании SQL Server:

• резервирует часть БД, которая изменилась с момента по­следнего полного резервирования. Для определения измененных страниц SQL Server сравнивает LSN на странице для синхронизации с LSN последнего резервирования;

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

Резервирование журнала транзакций применяется для записи любых изменений в БД. Метод рекомендуется использовать при выполнении полного резервирования БД. При этом журнал транзакций нельзя восстановить без соответствующего резерви­рования БД; журнал транзакций невозможно резервировать с помощью простой модели резервирования.

Резервирование файлов БД и файловых групп. Метод исполь­зуется в случае нецелесообразности полного резервного копиро­вания на очень больших БД. При резервировании файлов БД или файловых групп с помощью SQL Server:

• резервируются только те файлы, которые указаны в опции FILE или FILEGROUP;

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

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

При создании индекса в простой модели восстановления журнал транзакций фиксирует факт создания индекса и список страниц, которые использовались при этом. Использование это­го журнала транзакций во время восстановления БД приводит к тому, что SQL Server выполняет оператор CREATE INDEX и ис­пользует оригинальные страницы индекса.

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

3

ОСНОВНЫЕ ПОНЯТИЯ АИС. КЛАССИФИКАЦИЯ АИС.

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

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

Комплекс средств автоматизации (КСА)совокупность всех компонентов АС, за исключением персонала.

Пользователь АСлицо, участвующее в функционировании АС или использующее результаты ее функционирования.

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

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

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

Основываясь на степени автоматизации информационных процессов в системе управления фирмой (организацией), ИС делятся на:

-ручные;

-автоматические;

-автоматизированные.

По типу хранимых данных ИС делятся на:

-фактографические;

-документальные.

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

В автоматических ИС все операции по переработке инфор­мации выполняются без участия человека.

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

Классификация АИС с учетом особенностей автоматизируемой профессиональной деятельности:

АСУ — автоматизированные системы управления (П — персоналом, ТС — техническими средствами); СППР — системы поддержки принятия решения (Р — руководителя, О — должностного лица органа управления, Д — оперативного де­журного, Оп — оператора);

АИВС — автоматизированные информационно-вы­числительные системы;

ИРС — информационно-расчетная система;

САПР — система автоматизированного проектирования;

МЦ — моделирующий центр;

ПОИС — проблемно-ориентированная имитационная система;

АИИС — авто­матизированные информационно-справочные системы; АА — автоматизированные архивы;

АСД — автоматизированные системы делопроизводства;

АС — автоматизированные справочники и АК — автоматизированные картотеки;

АСВЭК — автоматизированные системы ведения электронных карт;

АСО — автоматизированные системы обучения;

АСОДИ — автоматизированные системы обеспечения деловых игр;

Т и ТК — тренажеры и тренажерные комплексы.

4

СОСТАВ И СТРУКТУРА ФУНКЦИОНАЛЬНЫХ ПОДСИСТЕМ АИС.

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

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

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

  • предметному;

  • функциональному;

  • проблемному;

  • смешанному (предметно-функциональному)

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

уровнях управления, обеспечивая интеграцию информационных потоков по вертикали

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

5

ПОНЯТИЕ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ АИС.

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

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

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

Методы проектирования АИС можно классифицировать:

-по степени использования средств автоматизации,

-типовых проектных решений,

-адаптивности к предполагаемым изменениям:

А) По степени автоматизации:

-ручное проектирование

-компьютерное проектирование

Б) По степени использования типовых проектных решений:

-оригинальное(с нуля)

-типовое проектирование(из готовых типовых проектных решений)

В) По степени адаптивности проектных решений:

-реконструкция (адаптация проектных решений выполняется путем переработки соответствующих компонентов)

-параметризация (проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами)

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

Выделяется два основных класса технологии проектирования АИС:

-каноническая;

-индустриальная.

Индустриальная технология проектирования АИС делится на 2 подкласса: автоматизированное(case-технологии) и

типовое проектирование (параметрически-ориентированное, модельно ориентированное).

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

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

  • технология должна максимально отражать все этапы цикла жизни проекта;

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

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

  • технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

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

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

6

СТАДИИ И ЭТАПЫ КАНОНИЧЕСКОГО ПРОЕКТИРОВАНИЯ АИС.

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

Стадия 1. Формирование требований к ИС.

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

• обследование объекта и обоснование необходимости создания ИС;

• формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

• изучение объекта автоматизации;

• проведение необходимых научно-исследовательских работ;

• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

• оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

• разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

• разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку комплектующих изделий;

• разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

• разработка рабочей документации на ИС и ее части;

• разработка и адаптация программ.

Стадия 7. Ввод в действие.

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

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

• послегарантийное обслуживание.

7

ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ АИС.

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

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

По степени автоматизации различают:

  • ручное проектирование, при котором проектирование компонентов АИС осуществляется без использования специальных инструментальных программных средств; програм­мирование производится на алгоритмических языках;

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

По степени использования типовых проектных решений различают:

  • оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС;

  • типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программных модулей).

Оригинальное проектирование АИС предполагает максимальный учет особенностей автоматизированного объекта.

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

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

  • реконструкция — адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

  • параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

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

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

Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (использование CASE-технологий) и

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

8

ЖИЗНЕННЫЙ ЦИКЛ АИС.

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

Базовые стандарты, определяющие процессы ЖЦ АИС:

-ГОСТ 34. 601-90–стандарт на стадии и этапы создания АИС.

- ISO/IEC 12207:1995 – стандарт на процессы и организацию ЖЦ ПО.

Стандарт ISO/IEC 12207 в структуре жизненного цикла определяет процессы, которые выполняются при создании ПО АИС. Эти процессы подразделяют на три группы:

основные (приобретение, поставка, разработка, эксплуатация и сопровождение);

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

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

Среди основных процессов жизненного цикла самыми важными являются:

- разработка,

- эксплуатаци,

- сопровождение.

Разработка АИС включает все работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями. Этот процесс также предусматривает:

• оформление проектной и эксплуатационной документации;

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

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

Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реали¬зация (программирование).

Эксплуатация АИС включает:

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

• обеспечение пользователей эксплуатационной документацией;

• обучение персонала.

Основные эксплуатационные работы:

• непосредственно эксплуатацию;

• локализацию проблем и устранение причин их возникновения;

• модификацию программного обеспечения;

• подготовку предложений по совершенствованию системы;

• развитие и модернизацию системы.

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

К предварительным действиям при организации технического обслуживания АИС относятся:

• выделение наиболее ответственных узлов системы и опре¬деление для них критичности простоя (это позволит выделить наиболее критичные составляющие АИС и оптимизи¬ровать распределение ресурсов для технического обслуживания);

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

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

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

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

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

Разработка сложных АИС предполагает независимую разработку компонентов системы, что приводит к появлению многих вариантов и версий реализации как отдельных компонентов, так и системы в целом. Таким образом, возникает проблема обеспечения сохранения единой структуры в ходе разработки и модернизации АИС. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты АИС на всех стадиях ее ЖЦ.

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

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков, контроля сроков и качества выполнения работ. Техническое и орга¬низационное обеспечение проекта включает:

• выбор методов и инструментальных средств реализации проекта;

• определение методов описания состояния процесса разра¬ботки;

• разработку методов и средств испытаний созданного про¬граммного обеспечения;

• обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов АИС.

Верификация — процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требова¬ниям этого этапа.

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

9

КАСКАДНАЯ, ИТЕРАЦИОННАЯ И СПИРАЛЬНАЯ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА АИС.

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

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

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

Процесс разработки по каскадной схеме.

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

Третий этап — реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с проектными решениями предыдущего этапа. Методы реализации

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

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

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

Достоинства каскадной модели:

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

Недостатки каскадной модели:

  1. существенная задержка в получении результатов;

  2. ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;

  3. сложность параллельного ведения работ по проекту;

  4. чрезмерная информационная перенасыщенность каждого из этапов;

  5. сложность управления проектом;

  6. высокий уровень риска и ненадежность инвестиций.

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

Достоинства итерационной модели: Межэтапные корректировки обеспечивют меньшую трудоемкость разработки по сравнению с каскадной моделью.

Недостатки:

  1. время жизни каждого этапа растягивается на весь период разработки;

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

  3. сложность архитектуры;

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

Процесс разработки АИС по итерационной схеме.

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

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

Спиральная модель АИС

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

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

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

Преимущества спираьной модели:

•итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

  • при использовании спиральной модели отдельные элементы АИС интегрируются в единое целое постепенно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (при использовании каскадной модели интеграция занимает до 40 % всех затрат в конце проекта);

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

Недостатки спиральной модели:

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

10

CASE-ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ЭИС.

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

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

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

В большинстве современных CASE-систем применяются методологии структурного и/или объектно-ориентированного анализа и проектирования, основанные на использовании наглядных диаграмм, графов, таблиц и схем.

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

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

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

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

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

- графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

- средства разработки приложений, включая языки 4GL и генераторы кодов;

- средства конфигурационного управления;

- средства документирования;

- средства тестирования;

- средства управления проектом;

- средства реинжиниринга (повторное использование программных компонент в новых проектах).

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям.

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ.

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

- применяемым методологиям и моделям систем и БД;

- степени интегрированности с СУБД;

- доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE - средств и включает следующие основные типы:

- средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (LogicWorks));

- средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

-Vantage Team Builder (Westmount I-CASE);

-Designer/2000;

-Silverrun;

-ERwin+BPwin;

-S-Designor;

-CASE.Аналитик.

11

ТЕХНОЛОГИЯ БЫСТРОГО ПРОЕКТИРОВАНИЯ АИС (RAD- ТЕХНОЛОГИЯ).

Методология быстрой разработки приложений RAD (Rapid Application Development) - процесс разработки программного обеспечения, содержащий 3 элемента:

  1. небольшую команду программистов (от 2 до 10 человек);

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

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

  1. фаза определения требований и анализа;

  2. фаза проектирования;

  3. фаза реализации;

  4. фаза внедрения.

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

Базовые принципы RAD – технологии:

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

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

-Управление проектом должно минимизировать длительность цикла разработки.

12

ОСНОВЫ СОВРЕМЕННЫХ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ.

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

Компоненты системы баз данных

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

Прикладные программы относятся к категории приложений.

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

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

Модель данных — описание принципов, на основе которых построена БД. При разработке БД используют инструментальные программные средства СУБД.

К числу основных функций СУБД относится следующие:

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

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

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

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

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

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

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

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

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

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

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

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

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

13

АРХИТЕКТУРЫ БАЗ ДАННЫХ.

В настоящее время архитектура БД рассматривается как трехуровневая модель:

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

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

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

Существуют следующие архитектурные решения баз данных:

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

Недостатки архитектуры:

  • низкая пропускная способность сети, большое время реакции;

  • зависимость целостности данных от прикладной программы;

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

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

Такая архитектура можно использоваться для небольшой БД при одновременной работе 5—10 пользователей.

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

Недостатки:

  • алфавитно-цифровой монохромный интерфейс;

  • сложность администрирования;

  • масштабируемость — увеличение числа пользователей приводит к необходимости аппаратной и программной модификации.

Архитектура «клиент—сервер». Предусматривает наличие двух типов программ: программы-клиента (активная) и программы-сервера (пассивная). Функции клиента: взаимодействие с пользователем. Функции сервера БД: выполнение клиентских запросов, предоставление механизма одновременного доступа к данным нескольких пользователей.

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

14

СТАНДАРТНЫЕ СИСТЕМЫ ДОСТУПА К БАЗАМ ДАННЫХ.

Существует несколько способов доступа к данным. Подавляющее большинство систем управления БД содержит в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (Application Programming InterfaceAPI) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов БД, а в случае серверных СУБД инициируют передачу запросов серверу БД и получение от сервера результатов выполнения запросов или кодов ошибок, интерпретируемых клиентским приложением. Библиотеки, содержащие API для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения.

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

Универсальный механизм доступа к данным — Universal Data Access (Microsoft) представляет собой стратегию предоставления доступа к любому типу информации. В результате обеспечивается высокопроизводительный доступ к различным источникам информации (включая реляционные и нереляционные данные), в том числе к данным, хранящимся на серверах, данным электронной почты и файловой системы, текстовым, графическим и географическим данным и др Универсальные механизмы ODBC, OLE DB и ADO фирмы Microsoft представляют собой по существу промышленные стандарты.

Назначение универсального механизма доступа к данным фирмы Microsoft — предоставить доступ к источникам данных с помощью единой модели доступа к данным. В настоящее время универсальный механизм доступа к данным фирмы Microsoft поддерживает все наиболее популярные настольные и серверные СУБД.

Основные компоненты архитектуры универсального механизма доступа к данным Microsoft:

1. Microsoft ActiveX Data Objects (ADO) — программный интерфейс для доступа к данным из приложений. С точки зрения программирования, ADO и его расширения являются упрощенным высокоуровневым объектно-ориентированным интерфейсом к OLE DB;

2. OLE DB — низкоуровневый интерфейс для доступа к данным. ADO использует OLE DB, но можно использовать OLE DB и напрямую, минуя ADO;

3. Open Database Connectivity (ODBC) — стандартный способ доступа к реляционным данным. Этот компонент универсального механизма доступа к данным оставлен с целью обеспечения совместимости с прежними версиями программного обеспечения. В современных приложениях применению ODBC-драйверов предпочитают использование OLE DB-провайдеров.

Архитектура универсального механизма доступа к данным Microsoft схематически представлена на рис.

Рис. Механизмы доступа к данным.

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

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

15

ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ.

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

- получение,

- сбор и регистрация информации,

- передача,

- хранение,

- обработка,

- выдача обработанной (результатной) информации,

- принятие решения для выработки управляющих воздействий.

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

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

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

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

16

КОМПОНЕНТЫ И СТРУКТУРЫ ИНФОРМАЦИОННЫХ ПРОЦЕССОВ В АИС.

Структура информационных процессов в АИС и их компоненты представлены на рисунке.

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

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

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

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

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

Машинное кодирование — процедура машинного представления (записи) информации на машинных носителях в кодах, при­нятых в ПЭВМ. Такое кодирование информации производится путем переноса данных первичных документов на магнитные диски, информация с которых затем вводится в ПЭВМ для обаботки.

Запись информации на машинные носители осуществляется на ПЭВМ как самостоятельная процедура или как результат об­работки.

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

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

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

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

Важное место в информационных процессах занимает автоматизация процесса принятия решений с помощью СППР (систем поддержки принятия решений).

17

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ. МЕТОДЫ РЕЗЕРВИРОВАНИЯ.

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

Полное резервирование БД. При использовании БД в основном только для чтения полное резервирование может быть наилучшим решением для предотвращения потери данных. Во время выполнения полного резервного копирования SQL Server:

  • резервирует любую активность, которая происходит во вре­мя резервирования;

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

Дифференцированное резервирование БД выполняется для сокращения времени, необходимого для восстановления часто изменяемой БД. Метод рекомендуется использовать в случае, если выполнено полное резервирование. При дифференцированном резервировании SQL Server:

• резервирует часть БД, которая изменилась с момента по­следнего полного резервирования. Для определения изме­ненных страниц SQL Server сравнивает LSN на странице для синхронизации с LSN последнего резервирования;

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

Резервирование журнала транзакций применяется для записи любых изменений в БД. Метод рекомендуется использовать при выполнении полного резервирования БД. При этом журнал транзакций нельзя восстановить без соответствующего резервирования БД; журнал транзакций невозможно резервировать с помощью простой модели резервирования.

Резервирование файлов БД и файловых групп. Метод используется в случае нецелесообразности полного резервного копирования на очень больших БД. При резервировании файлов БД или файловых групп с помощью SQL Server:

• резервируются только те файлы, которые указаны в опции FILE или FILEGROUP;

• резервируются только определенные файлы, а не вся БД.

18

МОДЕЛИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Рассмотрим базовые понятия надежности ПО:

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

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

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

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

Известные модели надежности программного и информационного обеспечения АСОИУ можно классифицировать по различным признакам, в частности по тому, какой из перечисленных процессов они поддерживают:

-предсказывающие,

-прогнозные,

-оценивающие,

-измеряющие.

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

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

Оценивание— определение количественных показателей надежности, основанное на данных об интервалах между отказами, полученных в процессе испытания ПО и ИО АСОИУ в реальных условиях функционирования.

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

Существует 2 группы моделей надежности ПО:

- Аналитические;

- Эмпирические.

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

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

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

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

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

Для оценки надежности используются три группы показателей: качественные, порядковые и количественные.

К основным количественным показателям надежности программного средства относятся:

Вероятность безотказной работы P(tз) — это вероятность того, что в пределах заданной наработки отказ системы не возникает.

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

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

Средняя наработка до отказа — математическое ожидание времени работы программного или информационного обеспечения АСОИУ до очередного отказа.

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

Коэффициент готовности Кг - вероятность того, что программное и информационное обеспечение АСОИУ будет находиться в работоспособном состоянии в произвольный момент времени его использования по назначению:

19

СОВРЕМЕННЫЕ СЕТЕВЫЕ ТЕХНОЛОГИИ.

Сетевая технология – это согласованный набор стандартных протоколов и реализующих их программно-аппаратных средств, достаточный для построения локальной вычислительной сети. Сетевые технологии называют базовыми технологиями или сетевыми архитектурами локальных сетей. Сетевая технология или архитектура определяет топологию и метод доступа к среде передачи данных, кабельную систему или среду передачи данных, формат сетевых кадров тип кодирования сигналов, скорость передачи в локальной сети. В современных локальных вычислительных сетях широкое распространение получили такие технологии или сетевые архитектуры, как: Ethernet, Token-Ring, ArcNet, FDDI и др.

К современным сетевым технологиям относятся:

Х.25,

Token-Ring

Frame Relay (FR),

FDDI

АТМ.

Сетями Х.25 называются сети, доступ к которым производится в соответствии с рекомендациями Международного консультативного комитета по телефонии и телеграфии (МККТТ), первый вариант которой появился в 1976 году. Эта рекомендация описывает интерфейс доступа пользователя в сеть передачи данных, а также интерфейс взаимодействия с удаленным пользователем через систему передачи данных (СПД). Передача данных в сети Х.25 производится по протоколам, описанным в рекомендации Х.25. С момента выпуска первого варианта рекомендации Х.25 все стандарты были практически проверены, расширены и дополнены, и сегодня достигнут высокий уровень совместимости оборудования, выпускаемого различными фирмами для сетей Х.25.

Несмотря на появление новых интегральных технологий сетей связи, рассчитанных на высокоскоростные каналы связи, сети Х.25 все еще являются наиболее распространенными СПД. Это объясняется тем, что именно сети Х.25 с наибольшим основанием можно сравнить с телефонными сетями: установив соединение компьютера с ближайшим узлом сети Х.25, можно связаться с любым из многих тысяч пользователей сетей Х.25 по всему миру (для этого надо лишь знать его сетевой адрес) точно так же, как подняв трубку телефонного аппарата, подключенного к ближайшей АТС, можно соединиться практически с любым абонентом.

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

Сетевые технологии локальных сетей:

Сетевые технологии локальных сетей IEEE802.3/Ethernet

В настоящее время эта сетевая технология наиболее популярна в мире. Популярность обеспечивается простыми, надежными и недорогими технологиями. В классической локальной сети Ethernet применяется стандартный коаксиальный кабель двух видов (толстый и тонкий). Однако  все большее распространение получила версия Ethernet, использующая в качестве среды передачи витые пары, так как монтаж и обслуживание их гораздо проще. В локальных сетях Ethernet применяются  топологии типа “шина” и типа “пассивная звезда”, а метод доступа CSMA/CD. Стандарт IEEE802.3 в зависимости от типа среды передачи данных имеет модификации:

 10BASE5 (толстый коаксиальный кабель) - обеспечивает скорость передачи данных 10 Мбит/с и длину сегмента до 500м;

 10BASE2 (тонкий коаксиальный кабель) - обеспечивает скорость передачи данных 10 Мбит/с и длину сегмента до 200м;;

 10BASE-T (неэкранированная витая пара) - позволяет создавать сеть по звездной топологии. Расстояние от концентратора до конечного узла до 100м. Общее количество узлов не должно превышать 1024;

 10BASE-F (оптоволоконный кабель) - позволяет создавать сеть по звездной топологии. Расстояние от концентратора до конечного узла до 2000м. В развитие сетевой технологии Ethernet созданы высокоскоростные варианты: IEEE802.3u/Fast Ethernet и IEEE802.3z/Gigabit Ethernet. Основная топология, которая используется в локальных сетях Fast Ethernet и Gigabit Ethernet, пассивная звезда. Сетевая технология Fast Ethernet обеспечивает скорость передачи 100 Мбит/с и имеет три модификации:

 100BASE-T4 - используется неэкранированная витая пара (счетверенная витая пара). Расстояние от концентратора до конечного узла до 100м;

 100BASE-TX - используются две витые пары (неэкранированная и экранированная). Расстояние от концентратора до конечного узла до 100м;  

 100BASE-FX - используется оптоволоконный кабель (два волокна в кабеле). Расстояние от концентратора до конечного узла до 2000м.

Сетевая технология локальных сетей Gigabit Ethernet – обеспечивает скорость передачи 1000 Мбит/с. Существуют следующие модификации стандарта:

 1000BASE-SX – применяется оптоволоконный кабель с длиной волны светового сигнала 850 нм.

 1000BASE-LX – используется оптоволоконный кабель с длиной волны светового сигнала 1300 нм.

 1000BASE-CX – используется экранированная витая пара.

 1000BASE-T – применяется счетверенная неэкранированная витая пара. Локальные сети Fast Ethernet и Gigabit Ethernet совместимы с локальными сетями, выполненными по  технологии (стандарту) Ethernet, поэтому легко и просто соединять сегменты Ethernet, Fast Ethernet и Gigabit Ethernet в единую вычислительную сеть.

Сетевые технологии локальных сетей IEEE802.5/Token-Ring

Сеть Token-Ring предполагает использование разделяемой среды передачи данных, которая образуется объединением всех узлов в кольцо. Сеть Token-Ring имеет звездно-кольцевую топологию (основная кольцевая и звездная дополнительная топология). Для доступа к среде передачи данных используется маркерный метод (детерминированный маркерный метод). Стандарт поддерживает витую пару (экранированную и неэкранированную) и оптоволоконный кабель. Максимальное число узлов на кольце - 260, максимальная длина кольца - 4000 м. Скорость передачи данных до 16 Мбит/с.

Сетевые технологии локальных сетей IEEE802.4/ArcNet

В качестве топологии локальная сеть ArcNet использует “шину” и “пассивную звезду”. Поддерживает экранированную и неэкранированную витую пару и оптоволоконный кабель. В сети ArcNet для доступа к среде передачи данных используется метод передачи полномочий. Локальная сеть ArcNet - это одна из старейших сетей и пользовалась большой популярностью. Среди основных достоинств локальной сети ArcNet можно назвать высокую надежность, низкую стоимость адаптеров и гибкость. Основным недостаткам сети является низкая скорость передачи информации (2,5 Мбит/с). Максимальное количество абонентов - 255. Максимальная длина сети - 6000 метров.

Сетевые технологии локальных сети FDDI (Fiber Distributed Data Interface)

FDDI– стандартизованная спецификация для сетевой архитектуры высокоскоростной передачи данных по оптоволоконным линиям. Скорость передачи – 100 Мбит/с. Эта технология во многом базируется на архитектуре Token-Ring и используется детерминированный маркерный доступ к среде передачи данных. Максимальная протяженность кольца сети – 100 км. Максимальное количество абонентов сети – 500. Сеть FDDI - это очень высоконадежная сеть, которая создается на основе двух оптоволоконных колец, образующих основной и резервный пути передачи данных между узлами.

ATM  (Asynchronous Transfer Mode) — асинхронный способ передачи данных) сетевая высокопроизводительная технология коммутации и мультиплексирования, основанная на передаче данных в виде ячеек (cell) фиксированного размера (53 байта), из которых 5 байтов используется под заголовок. В отличие от синхронного способа передачи данных (STM — англ. Synchronous Transfer Mode), ATM лучше приспособлен для предоставления услуг передачи данных с сильно различающимся или изменяющимся битрейтом (аудио. видео-данные).

Сеть ATM строится на основе соединенных друг с другом АТМ-коммутаторов. Технология реализуется как в локальных, так и в глобальных сетях. Допускается совместная передача различных видов информации, включая видео, голос.

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

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

Работать с постоянными и переменными потоками данных;

Интегрировать на одном канале любые виды информации: данные, голос, потоковое аудио- и видеовещание, телеметрия и т.п.;

Поддерживать соединения типа точка–точка, точка–многоточка и многоточка–многоточка.

Технология ATM предполагает межсетевое взаимодействие на трёх уровнях.

Для передачи данных от отправителя к получателю в сети ATM создаются виртуальные каналы, VC (англ. Virtual Circuit), которые бывают трёх видов:

постоянный виртуальный канал, PVC (Permanent Virtual Circuit), который создаётся между двумя точками и существует в течение длительного времени, даже в отсутствие данных для передачи;

коммутируемый виртуальный канал, SVC (Switched Virtual Circuit), который создаётся между двумя точками непосредственно перед передачей данных и разрывается после окончания сеанса связи.

Кольца в сетях FDDI рассматриваются как общая разделяемая среда передачи данных, поэтому для нее определен специальный метод доступа. Этот метод очень близок к методу доступа сетей Token Ring и также называется методом маркерного (или токенного) кольца - token ring.

Отличия метода доступа заключаются в том, что время удержания маркера в сети FDDI не является постоянной величиной, как в сети Token Ring. Это время зависит от загрузки кольца - при небольшой загрузке оно увеличивается, а при больших перегрузках может уменьшаться до нуля. Эти изменения в методе доступа касаются только асинхронного трафика, который не критичен к небольшим задержкам передачи кадров. Для синхронного трафика время удержания маркера по-прежнему остается фиксированной величиной. Механизм приоритетов кадров, аналогичный принятому в технологии Token Ring, в технологии FDDI отсутствует. Разработчики технологии решили, что деление трафика на 8 уровней приоритетов избыточно и достаточно разделить трафик на два класса - асинхронный и синхронный, последний из которых обслуживается всегда, даже при перегрузках кольца.

20

МЕТОДЫ ПОВЫШЕНИЯ НАДЕЖНОСТИ ПРОГРАММНО-ТЕХНИЧЕСКИХ КОМПЛЕКСОВ.

Существует четыре группы мероприятий по повышению надежности программо-технических комплексов при их проектировании:

- системные;

- структурные (схемные);

- конструктивные;

- ксплуатационные.

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

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

Технические мероприятия по оформлению показателей надежности проектируемых ТС необходимы при любой системе взаимоотношений заказчика и разработчика. К техническим мероприятиям относятся учет внешних воздействий на проектируемые технические средства:

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

  2. климатические (температура, влажность, примеси в воздухе);

  3. биологические (грибок или плесень, насекомые, грызуны).

Структурные (схемные) методы объединяют мероприятия по повышению надежности ТС путем совершенствования принципов их построения.

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

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

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

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

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

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

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

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

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

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

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

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