Взгляд со стороны на языки программирования InTouch и Citect

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

В основную поставку InTouch входит набор до 100 функций. Но следует отметить, что:

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

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

- возможна разработка новых функций с использованием FactorySuite Toolkit и Visual C/C++.

Язык Cicode в Citect разработан на базе С/С++. Набор встроенных функций в системе превышает 700. Разработка новых функций производится способом, свойственным традиционным языкам программирования.
Синтаксический анализ программного кода в редакторе скриптов системы InTouch осуществляется в момент сохранения скрипта. При наличии ошибок диалог редактора скриптов не закрывается кнопкой Ok до тех пор, пока все ошибки не будут исправлены. При этом курсор каждый раз указывает на первую ошибку в списке.
В Cicode синтаксический анализ программы выполняется на этапе компиляции файла Cicode. В этом языке используются свойственные традиционным языкам средства отладки: точки останова, пошаговое исполнение и т. д.
В InTouch существуют функции для отладки, которые позволяют выводить в специальный файл (Wonderware Logger) статусную информацию о выполнении скриптов.
Использование Cicode требует более квалифицированной подготовки разработчиков приложений, особенно, если планируется создание многочисленных дополнительных функций.

Подсистема защиты

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

Администратор должен иметь доступ ко всем приложениям системы для устранения сбоев в системе при ее некорректной работе.

Она ограничивает доступ к:

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

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

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

Операторы входят в систему вручную, используя специальную программу Login (Вход). Данная программа позволяет пользователям ввести их входные имена и пароли.

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

В SCADA-системе ведется контрольный журнал защиты, в котором записываются сведения о каждой попытке входа. Читая контрольный журнал можно узнать:

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

Лекция №9

БАЗЫ ДАННЫХ

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

От прошлого к настоящему

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

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

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

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

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

Индустрия РБД в настоящее время вполне созрела. Условия на рынке сейчас диктует "большая пятерка": IBM, Informix, Microsoft, Oracle и Sybase. На нее падает львиная доля всех расходов на разработку БД. Можно выделить две категории приложений в БД: оперативная обработка транзакций (OLTP - Online Transaction Processing) и системы поддержки принятия решений (DSS - Decision Support System).

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

DSS (Decision Support System)-системы поддержки принятия решений, как правило, крупнее, чем OLTP-системы. Обычно они используются с целью анализа данных и выдачи отчетов и рекомендаций. Пользователи должны иметь возможность конструировать запросы различной степени сложности, осуществлять поиск зависимостей, выводить данные на графики и использовать информацию в других приложениях типа электронных таблиц, текстовых процессорах и статистических пакетов. Еще более широкую поддержку в процессе принятия решений обеспечивают системы оперативной аналитической обработки (OLAP - Online Analytical Processing).

Критерии оценки БД

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

Однако наиболее важные критерии оценки БД останутся теми же самыми, а именно:

· Повышает ли БД возможности конечных пользователей путем предоставления доступа к нужной информации в нужном месте и в нужное время?

· Обеспечивает ли БД требуемый уровень открытости и гибкости запросов?

· Легко ли сопровождать и использовать БД? Надежна ли она?

· Широко ли распространена БД и хорошо ли поддерживается ее технология большим числом независимых производителей программного обеспечения?

· Легко ли интегрировать БД с широким спектром иного программного обеспечения?

· Широк ли спектр возможных применений БД?

· Доступны ли по цене большинству пользователей аппаратные платформы, поддерживаемые БД?

· Приемлема ли сама БД по цене для большинства пользователей?

Клиент-серверные технологии

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

Для интерфейса в клиент-серверных системах используется SQL - язык структурированных запросов (Structured Query Language). Он представляет собой средство организации, управления и поиска информации в РБД. Широкое признание SQL приобрел благодаря таким своим характеристикам, как:

независимость от поставщика;
переносимость на разные компьютерные платформы;
опора на реляционные принципы хранения информации;
высокоуровневая англоязычная структура;
интерактивное выполнение запросов;
полнофункциональный язык БД;
поддержка со стороны IBM, Oracle, Sybase, Microsoft и др.

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

Взгляд со стороны на языки программирования InTouch и Citect - student2.ru