Программные продукты и системы

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

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

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

-    систематизированным синтаксисом языка;

-    широким набором стандартных библиотечных функций;

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

-    широким набором коммерческих библиотек;

-    возможностью использования графического представления информации;

-    наличием интегрированной среды.

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

Его основные преимущества перед традиционными подходами состоят в следующем:

-    повышение читаемости программы, более четкое представление ее структуры;

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

Объектно-ориентированное программирование характеризуют 3 основных свойства:

- инкапсуляция: объединение данных с процедурами и функциями, их обрабатывающими, что приводит к новому типу данных - объекту;

-    наследование: построение иерархии объектов с наследованием доступа каждого порожденного объекта к данным и программному коду предков;

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

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

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

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

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

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

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

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

-   размещение на экране полей редактирования и подсказок;

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

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

-    проверка на допустимость введенной информации;

-    осуществление операций постредактирования поля (вывод новых полей и подсказок, осуществление различных вычислений);

-    обновление экрана при выполнении определенных команд пользователя;

-    обработка команд, введенных пользователем;

-    обработка ошибочных ситуаций;

-    заполнение пауз в работе пользователя.

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

На рисунке 1 базовые объекты MemoObj и ESRObj содержат все методы, соответствующие перечисленным функциям.

Рис 1. Иерархия объектов системы "Свойства"

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

Другим разделом системы, позволяющим эффективно использовать методы объектно-ориентированного программирования, является раздел, осуществляющий прогнозирование свойств стекла, что также иллюстрируется рисунком 1. Здесь базовым является объект Ident, осуществляющий МНК-оценку параметров простейших моделей: линейной и квадратичной. Свойства этого объекта используются для построения прикладного объекта Filter, формирующего выборку свойств из архива, интерполирующего пропуски в измерениях. Возможности объекта Ident используются при создании объекта Models, осуществляющего оценку параметров моделей прогноза, входящих в базовый набор, a Models, в свою очередь, используется для создания объектов, реализующих адаптивный алгоритм без использования экзаменующей выборки (РгОЬ) и с ее использованием (РгЕх).

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

Рис. 2, Схема организации модулей в системе "Свойства"

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

Еще одной проблемой, возникающей при проектировании программных систем, является разработка структуры данных и схемы информационных потоков между модулями и объектами. Эта проблема может быть условно разделена на две части: разработка структуры базы данных и структуры данных, обеспечивающих взаимодействие модулей и объектов. В базе данных хранится справочная информация, характеризующая процесс выработки стекла и содержащая полное информационное обеспечение системы. На основе этой информации формируются локальные группы данных для обеспечения конкретных функций системы. Данные, характеризующие технологический процесс, можно условно разделить на информацию, относящуюся к сырьевым материалам; информацию, характеризующую марки стекол, вырабатывающиеся на предприятии; информацию, отражающую специфику конкретных печей. В соответствии с этим делением была предложена структура базы данных, представленная на рисунке 3. Как видно из этого рисунка, база данных состоит из трех разделов: СЫРЬЕ, СТЕКЛА, ПЕЧИ, каждый из которых представляет собой набор однородных записей. Запись содержит информацию о каком-либо объекте раздела: сырьевом материале, марке стекла или печи.

Помимо основных разделов, база данных содержит списки наименований, использующихся в различных разделах. Так, например, наименования сырьевых материалов, введенные пользователем при формировании раздела СЫРЬЕ, используются в подразделе "Характеристики шихты" раздела ПЕЧИ. Поэтому для обеспечения идентичности наименований при ведении раздела СЫРЬЕ автоматически должен формироваться список наименований материалов, с тем чтобы при ведении раздела ПЕЧИ для заполнения соответствующих полей пользователь уже не вводил повторно наименования вручную, а лишь выбирал их из упомянутого списка. Аналогично должны формироваться и использоваться списки наименований окислов, марок стекол и печей. Таким образом обеспечивалась бы идентичность соответствующих наименований в различных разделах и существенно снизилась бы трудоемкость ведения базы данных. Предложенная модель базы данных в соответствии с общепринятой классификацией относится к сетевым моделям.

При разработке систем, содержащих базу данных, обычно встает вопрос о выборе системы для ее ведения (СУБД). В данном случае это задача выбора между использованием одной из типовых систем и разработкой индивидуальной СУБД . Здесь, с одной стороны, типовая система обеспечивает широкий набор функций по ведению базы данных, легкость стыковки с другими базами того же типа и программной реализации. С другой стороны, система, специально разработанная для данного случая, способна обеспечить большее быстродействие, компактность, а также легкость стыковки с основной системой. Кроме того, практически все популярные СУБД (dBase, Paradox, FoxPro и т.п.) обрабатывают лишь плоские файлы (двухмерные таблицы), а следовательно, в нашем случае необходимо преобразование модели, изображенной на рисунке 3, в реляционную за счет внесения в нее избыточности. Помимо увеличения необходимой емкости запоминающих устройств, это приведет к усложнению алгоритма формирования рабочих выборок и базы данных. Учитывая также, что в каждом разделе базы данных содержится от 3 до 25 записей, пропадает необходимость использования системы сложных запросов и сортировок, предоставляемых типовыми СУБД. Проанализировав преимущества и недостатки обоих подходов, было решено остановить свой выбор на разработке индивидуальной СУБД и использовании для ее создания системы программирования Turbo-Pascal. Для ведения базы данных были определены три основные команды: вставка пустой записи, удаление записи и листание записей, которые позволили бы как создавать, так и редактировать разделы.

Рис.3. Структура базы данных.

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

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

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

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

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

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

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