Билет № 16

1. Особенности разработки автоматизированной системы управления (АСУ).

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

АСУ состоит из 2 частей:1) система обработки данных; и 2)модуль формирования управляющих решений.

Система обработки данных – это обычная база данных, в задачи которой входят сбор, классификация информации, составление некоторых отчетов.

Модуль формирования управляющих решений

Задачи:

1. Ограничение внешней среды от системы;

2. Решить вопрос, рассматривается ли система как изолированная или как открытая, со взаимосвязями с внешней средой.

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

Задача управления:

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

Формирование управляющего воздействия:

• 

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

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

В АСУ - вырабатывается искусственно;

В самоорганизующихся системах - - находится внутри системы.

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

Особенности затруднений при разработке АСУ:

1. Неоднозначность понятий цель и средства, система и подсистема.

2. Трудность прогнозирования поведения системы при изменении её компонентов.

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

1. Целеобразование – формирование цели в зависимости от условий.

2. Вариативность – это устойчивость системы к различным вариантам реализации.

3. Развиваемость – это способность изменять структуру без катастрофических последствий для системы.

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

Как любая сложная система АСУ состоит из двух частей: 1.Функциональная часть. 2.Обеспечивающая часть.

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

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

2. Целостность базы данных. Средства обеспечения целостности средствами SQL.

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

1) Целостности объектов. В частности оно задает ограничение на значения атрибутов, которые должны принадлежать определенному домену и накладывает запрет на неопределенные значения атрибутов первичного ключа отношения. Первичный ключ – минимальный идентификатор, который используется для уникальной идентификации картежа. Это значит, что никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации картежей. Если допустить присутствие определителя NULL в любой части первичного ключа, это равноценно утверждению, что не все его атрибуты необходимы для уникальной идентификации картежей, что противоречит определению первичного ключа.

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

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

• Запретить удаление записи в ссылочном отношении, если в ссылающемся отношении есть кортеж, в котором значение внешнего ключа совпадает со значением первичного ключа в ссылочном отношении.

• Выполнить каскадное удаление. При удалении записи в ссылочном отношении, удалить все соответствующие записи в ссылающемся отношении.

При выполнении операции редактирования следует:

• Запретить обновление первичного ключа записи в ссылочном отношении, если в ссылающемся отношении есть кортеж, в котором значение внешнего ключа совпадает со значением первичного ключа в ссылочном отношении.

• Выполнить каскадное редактирование. При редактировании записи в ссылочном отношении, отредактир-ть все соответствующие записи в ссылающемся отношении.

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

Кроме 2-х основных правил существует корпоративное ограничение целостности - дополнительные правила поддержки целостности данных, определяемые пользователями или администратором БД. Например, если в одном отделении не может работать больше 20 сотрудников, то пользователь может указать это правило, а СУБД следить за его выполнением.

3. Модели надёжности программного обеспечения. Сравнение моделей оценки надежности программного обеспечения. Перспективы построения «хороших» моделей оценки надежности программного обеспечения.

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

4. Критерии оценки надежных компьютерных систем. Оранжевая книга.

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

Надежность систем оценивается по двум основным критериям:

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

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

В "Оранжевой книге" рассматривается два вида гарантированности:

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

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

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

Включает: Тестирование; Доступность системы; Надежность системы; Верификация описания системы.

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

Граница НВБ – периметр безопасности. Компоненты вне НВБ могут быть ненадежными, но это не должно менять ее надежность в целом.

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

От монитора обращений требуется выполнение 3 свойств:

• Изолированность - монитор д. б. защищен от отслеживания своей работы;

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

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

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

5. Типичные схемы построения многосегментных LAN.

Пример: Предприятие располагается в трехэтажном здании.

Схема 1: LAN на основе сервера или моста.

Все задачи коммутационного оборудования (в т.ч. маршрутизации) возлагаются на сервер.

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

Схема 2: LAN на основе коммутаторов.

В зависимости от трафика возможны варианты:

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

(Для небольшого трафика)

Схема 3: LAN на основе маршрутизаторов.

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

Схема 4: На основе Backbone.

Между сегментами сети прокладывается основная высокоскоростная магистраль - Backbone.