CC BY
95
Общетехнические и социальные проблемы
271
Заключение
Сравнивая паспортные данные воздуходувок и их реальные рабочие характеристики (табл. 4, 5), следует отметить существенное ухудшение всех технических показателей воздуходувок, вызванное их физическим износом. Относительное снижение эксплуатационных показателей приведено в таблице 6.
ТАБЛИЦА 6. Относительное изменение технических показателей воздуходувок
Воздуходувка АР2, % Показатели АУэл, % А/эл ,
ВД 602 2,3 9,6 8,3
ВД 604 4,9 9,0 4,5
ВД 613 16,4 5,5 6,4
Износ воздуходувок (на момент проведения испытаний) приводит к существенному перерасходу электрической энергии на их привод, который составляет от 5,5% до 9,6% в зависимости от технического состояния агрегатов. В денежном выражении перерасход электроэнергии из-за износа этих воздуходувок при числе часов их эксплуатации, равном 2000, и тарифе на электроэнергию 1,1 руб/ (кВт • ч) в среднем составляет 176 тыс. руб/год на одну воздуходувку.
УДК 681.324 М. Л. Глухарёв
РАЗРАБОТКА ПОКАЗАТЕЛЕЙ И МЕТОДОВ ОЦЕНИВАНИЯ КОРРЕКТНОСТИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
Качество информационных систем существенно зависит от качества баз данных, которые в настоящее время нередко играют роль ядра информационных систем. В статье раскрывается понятие корректности баз данных, приводится классификация видов корректности, рассматриваются количественные и качественные показатели корректности. Изложены принципы построения автоматизированной системы проведения верификации баз данных.
недекларированные возможности, верификация, корректность баз данных, показатели корректности, метрики сложности программ, автоматизированная система проведения верификации.
ISSN 1815-588 X. Известия ПГУПС 2008/1
ОШцетехнические и социальные проблемы
Введение
Оценивание качества программного обеспечения (ПО) информационных систем (ИС) неразрывно связано с процессом верификации, т. е. с подтверждением того, что функциональные возможности ПО соответствуют их описаниям в программной документации. Функциональные возможности, которые не имеют описания в документации или не соответствуют описанию, называются не декларированными возможностями (НДВ) [1]. Они могут являться как следствием ошибок разработчика, так и результатом выполнения умышленно внедрённого в программу кода. Как случайные, так и преднамеренные НДВ (последние называются также программными закладками) представляют угрозу информационной безопасности программных систем. Цель верификации программ - выявление и регистрация НДВ для последующего их устранения.
Любое программное средство обладает определённой корректностью. Понятие корректность является более узким, чем понятие качество, так как последнее включает в себя такие характеристики, как надёжность, мобильность, понятность, сопровождаемость программной системы. Корректность характеризует функциональные возможности программы, т. е. одну из составляющих качества. Можно считать программу абсолютно корректной, если в ней отсутствуют НДВ. Однако на практике не удаётся избежать появления случайных НДВ, поэтому абсолютно корректных программ не встречается. Кроме того, говоря о корректности программного продукта, всегда подразумевают его соответствие некоторому эталонному объекту или совокупности формализованных эталонных характеристик и правил.
Корректность программы наиболее полно определяется степенью её соответствия программной спецификации. При отсутствии полностью формализованной спецификации в качестве эталона иногда используются неформализованные представления разработчика, пользователя или заказчика программ. В результате эталон, которому должна соответствовать программа, часто оказывается неопределенным, неточным и понятие корректности становится субъективным. С другой стороны, сами по себе формальные спецификации могут оказаться некорректными с точки зрения заказчика, поэтому для любой программы, корректной относительно спецификаций, существует риск обнаружения его некорректности относительно требований заказчика или пользователя.
Из сказанного следует, что связь между процессом верификации и обеспечением корректности ПО такова: верификация способствует
повышению корректности, но не стопроцентному её обеспечению.
Оценивание качества ИС неразрывно связано с верификацией всех её компонентов. В настоящее время существует множество методов и средств
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
273
автоматизированной верификации ПО, часто применяемых совместно, взаимно дополняющих друг друга. Но не менее важным, чем ПО, компонентом ИС является база данных (БД). Она также оказывает влияние на качество ИС и нуждается в верификации. Для проведения полноценной верификации требуется:
• правильное понимание сущности БД;
• система количественных и качественных показателей корректности БД;
• наличие автоматизированных систем верификации БД.
Сущность БД раскрывается в первом разделе настоящей статьи.
Основная задача здесь - показать, что БД на современном этапе развития представляют собой не только хранилища информации, но и программные компоненты ИС. В том же разделе приводится перечень существующих показателей корректности БД, наиболее часто встречающихся на практике, обосновывается необходимость введения новых показателей.
Второй раздел посвящён доработке системы показателей корректности БД и их классификации. Представленная система показателей не претендует на окончательность и может быть дополнена. Особенно это касается тех случаев, когда при оценивании корректности нужно учитывать специфику СУБД.
В третьем разделе представлена схема автоматизированной системы проведения верификации БД, ориентированная на обработку реляционных БД и СУБД Microsoft SQL Server. Изложены основные принципы её построения и функционирования.
1 База данных как программный компонент информационной системы
Важным компонентом ИС является база данных (БД). На современном этапе БД должны рассматриваться не только как хранилища данных, но и как полноценные программные компоненты. Обоснованием данного положения служит практика использования промышленных СУБД и ИС, основанная в значительной степени на использовании клиентсерверной архитектуры и технологии активного сервера. Суть последней заключается в том, что функции ИС, выполняющие обработку данных в БД, реализуются не в клиентских приложениях, а на стороне сервера СУБД в виде хранимых подпрограмм БД. Слово «хранимый» указывает на то, что коды этих подпрограмм располагаются вместе с данными и являются, таким образом, объектами БД.
Известно три типа хранимых подпрограмм: функции, процедуры и триггеры.
Функции и процедуры запускаются на выполнение путём явного вызова. Клиентскому приложению, чтобы вызвать процедуру, необходимо
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
предварительно соединиться с БД, где расположен её откомпилированный код. Обращение к процедуре производится по имени с передачей входных данных и, возможно, с заданием выходных параметров. Функция отличается от процедуры тем, что она всегда возвращает атомарное значение определённого типа и вызывается путём использования в арифметических и логических выражениях на месте операнда.
Наконец, триггер - это специальный тип хранимых подпрограмм. Он выполняется автоматически в ответ на вставку, обновление или удаление записей в таблице и служит для поддержания корректности и согласованности (целостности) данных. Реализация хранимых подпрограмм возможна как на языке баз данных, так и на языках программирования высокого уровня C, C++, Pascal, Java и т. п. [2].
Из сказанного следует, что БД, поддерживаемые промышленными СУБД (такими как Oracle, Microsoft SQL Server, DB2), имеют двойственную природу. Оставаясь хранилищами данных, они одновременно играют роль программного обеспечения в ИС или, точнее, становятся полноценными программными компонентами, напоминающими динамически подключаемые библиотеки операционной системы Windows или COM-объекты. Налицо сращивание данных с методами их обработки в одной сущности - базе данных.
Подобное сращивание в терминах объектно-ориентированного и компонентно-ориентированного подходов получило название инкапсуляции. Есть все основания утверждать, что БД, будучи программным компонентом, инкапсулирует данные и методы их обработки. При этом именно БД в составе ИС является активным сервером, работающим в среде СУБД, подобно тому, как обычный EXE-или DLL-файл работает в среде операционной системы.
Как и любая другая часть ИС, БД нуждаются в верификации и тестировании. Учитывая то, что верификация есть подтверждение корректности, необходимо заметить, что корректность БД должна оцениваться при помощи системы математических показателей.
К числу наиболее часто встречающихся сегодня на практике функциональных показателей корректности БД относятся следующие [3]:
• полнота накопленных описаний объектов - относительное число объектов и документов, имеющихся в БД, к общему числу объектов в аналогичной БД;
• достоверность - степень соответствия записей БД реальным объектам в данный момент времени;
• идентичность данных - относительное число описаний объектов, не содержащих ошибки, к общему числу документов об объектах в БД;
• актуальность данных - относительное число устаревших данных к общему числу накопленных и обрабатываемых записей.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
275
Помимо функциональных показателей, существуют конструктивные показатели корректности, отличающиеся большей универсальностью, независимостью от сферы применения базы данных:
• объём БД - число описаний объектов или документов в БД, доступных для хранения и обработки;
• оперативность - степень соответствия динамики изменения данных в процессе сбора и обработки состояниям реальных объектов, или величина запаздывания между появлением (изменением) характеристик реального объекта и его отражением в БД;
• периодичность - промежуток времени между поставками двух последовательных, достаточно различающихся информацией версий БД;
• глубина ретроспективы - интервал времени от даты выпуска (записи в БД) самого раннего документа до настоящего времени;
• динамичность - относительное число изменяемых описаний объектов к общему числу записей в БД за некоторый интервал времени, определяемый периодичностью издания версий БД.
Нетрудно видеть, что все перечисленные показатели корректности затрагивают содержимое таблиц БД, но не отражают её логическую структуру. С их помощью нельзя оценить качество схемы БД, нельзя установить, нормализованы ли таблицы, обеспечена ли целостность информации на логическом и внешнем уровнях абстрагирования. Наконец, согласно изложенному выше, БД на современном этапе развития ИС является программным компонентом. Поэтому к БД применимы многие характеристики ПО, на основе которых определяется корректность поведения программных систем и, в частности, проверяется отсутствие НДВ.
2 Виды и показатели корректности баз данных
Оценивание корректности БД предполагает анализ её содержимого, логической структуры и программной составляющей (хранимых подпрограмм). В связи с этим необходимо различать три вида корректности БД: корректность содержимого, корректность схемы данных и программная корректность. Рассмотрим каждый из перечисленных видов по отдельности.
2.1 Корректность содержимого
Любая запись в БД должна адекватно отражать характеристики реального существующего объекта, экземпляра сущности предметной области; если же в записи фиксируется информация о взаимодействии объектов, то речь должна идти о взаимодействии, имеющем место в реальной действительности.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Юйцетехнические и социальные проблемы
Очевидно, что корректность содержимого определяется функциональными и конструктивными показателями, рассмотренными в предыдущем разделе (см. также [3]).
2.2 Корректность схемы данных
Традиционно под реляционной схемой понимается набор взаимосвязанных схем отношений или, с точки зрения обычного пользователя, весь набор таблиц БД. В данной работе предлагается более широкое понимание этого термина, а именно: совокупность логически связанных друг с другом таблиц, представлений, индексов, ограничений целостности и умолчаний. Можно выделить следующие подвиды корректности схемы данных.
1. Точность отображения концептуальной схемы (ER-схемы) на реляционную. Концептуальная модель реляционной БД обычно представляется в виде диаграмм сущность-связь, или ER-диаграмм, на которых показываются объекты предметной области и связи (способы взаимодействия) между ними. При концептуальном проектировании не оперируют понятиями «таблица», «внешний ключ» и т. п. Но ER-диаграммы легко преобразуются в схему реляционной БД по набору типовых правил. В итоге сущностям, представленным на ER-схеме, соответствуют таблицы реляционной БД, а связям - вспомогательные таблицы и внешние ключи. Типовые правила отображения дают возможность «обратного проектирования» - получения ER-схемы по имеющейся реляционной схеме БД. Однако не всегда «обратное проектирование» даёт ER-схему, эквивалентную исходной концептуальной модели. Причиной этого в ряде случаев является неточность прямого преобразования, в результате чего схема БД получается некорректной по отношению к исходной ER-модели.
Точность отображения, очевидно, может быть определена как соответствие ER-схемы, полученной в результате «обратного проектирования», исходной концептуальной схеме. Точность отображения характеризуется множеством показателей, учитывающих детализацию сравнения на уровне атрибутов, сущностей, связей и участков ER-диаграмм, образованных двумя отдельно взятыми сущностями и одной ассоциацией между ними.
В каждом случае необходимо рассчитывать относительное число правильно отображённых на реляционную схему сущностей, атрибутов, связей и участков, к общему числу соответствующих элементов, определённых на этапе концептуального проектирования. С другой стороны, в процессе создания реляционной схемы могут появиться недекларированные атрибуты, сущности и связи. Процесс верификации БД
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
277
должен включать в себя оценивание их процентного содержания в общем числе отражённых на реляционной схеме сущностей, атрибутов и связей соответственно. Чем ниже процентное содержание не декларированных элементов схемы данных, тем корректнее БД по отношению к концептуальной модели.
2. Нормализованность таблиц. Основная цель проектирования БД -группирование атрибутов по таблицам так, чтобы минимизировать избыточность данных и по возможности сократить объём памяти, необходимый для физического хранения таблиц. Теория нормальных форм и нормализации описывает один из формальных методов проектирования БД, в котором идентификация таблиц основана на выявлении первичных ключей и функциональных зависимостей между атрибутами [4].
Высшей нормальной формой на практике оказывается, как правило, нормальная форма Бойса-Кодда. Согласно её требованиям, все неключевые атрибуты таблицы должны полностью функционально зависеть от потенциального ключа, а функциональных зависимостей между различными неключевыми атрибутами быть не должно. Нарушение этих требований приводит к избыточности данных и, как следствие, к аномалиям вставки, обновления и удаления записей.
Современные методы проектирования (в том числе упомянутый ранее метод ER-моделирования) позволяют автоматически приводить таблицы БД к нормальной форме Бойса-Кодда. Однако ошибки могут возникать, особенно если разработчиками принимается нешаблонное решение о частичной денормализации таблиц.
Проще всего оценивать нормализованность БД при помощи относительного числа полностью нормализованных таблиц к общему числу таблиц. Более сложной задачей является оценивание степени допустимости денормализации для данного проекта, если таковая имеет место.
3. Логическая целостность. Важной составляющей корректности схемы данных является логическая целостность. С каждой предметной областью связаны определённые требования целостности, которые тем или иным образом ограничивают диапазоны возможных значений атрибутов сущностей и связей, говорят о допустимости либо недопустимости комбинаций некоторых значений. Реализация требований целостности в БД позволяет избавиться от появления отрицательных возрастов и масс, от повторения одного и того же ИНН у различных лиц, от некорректной последовательности дат начала и завершения работы (в случае, когда они в результате ошибки пользователя меняются местами) - словом, избежать появления логически противоречивой, несогласованной, «невозможной» с позиции здравого смысла информации.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
Простые требования целостности реализуются при помощи специальных объектов БД, называемых ограничениями. Большинством реляционных СУБД сегодня поддерживаются такие ограничения целостности, как первичный ключ, внешний ключ, уникальность значений, запрет неопределённых значений и ограничение на основе логического условия. Более сложные требования целостности реализуются процедурно с помощью специальных подпрограмм - триггеров. Следует заметить, что целостность в данном случае пересекается с программной корректностью, которая будет рассматриваться далее. И в первом, и во втором случае речь идёт об автоматическом поддержании целостности. Во время выполнения операций вставки, удаления и обновления неверные данные либо не принимаются совсем, либо автоматически корректируются.
Целесообразно оценивать логическую целостность БД при помощи следующих показателей.
3.1. Полнота реализации требований целостности - отношение реализованных в БД ограничений и триггеров к общему числу заявленных требований. Ограничения, которые не были заявлены в документации, не рассматриваются.
3.2. Относительное число не заявленных в документации ограничений целостности к общему числу реализованных. Если недекларированных ограничений нет, показатель принимает нулевое значение, что говорит о корректности схемы данных.
3.3. Согласованность ограничений с содержимым таблиц. Возможны ситуации, когда дополнительное ограничение целостности или новый триггер добавляются в уже заполненную БД. При этом нельзя допустить, чтобы новое ограничение вошло в противоречие с уже добавленными в таблицы записями. Для обычных ограничений целостности эта проблема решена на уровне СУБД. Система запрещает вводить ограничение, если в БД уже имеются строки таблиц, которые ему не удовлетворяют. Но СУБД не в состоянии выполнить подобную проверку для триггера. Поэтому возможны противоречия: с одной стороны, имеется сложное ограничение целостности, реализуемое триггером; с другой стороны, записи, появившиеся в БД до создания триггера, могут заведомо не удовлетворять этому ограничению.
Показатель согласованности ограничений и содержимого таблиц рассчитывается как отношение записей, удовлетворяющих всем ограничениям, к общему числу записей. Расчёт этого показателя неразрывно связан с анализом программного кода триггеров, цель которого - выяснить декларативный смысл каждого триггера. Задача эта сама по себе нетривиальна и требует отдельного рассмотрения.
3.4. Непротиворечивость ограничений. В результате ошибок проектирования в БД могут возникать конфликты между ограничениями и
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
279
триггерами. Когда разные триггеры и ограничения предъявляют к данным противоречивые требования, вплоть до взаимоисключающих, таблицы БД могут оказаться недоступными для вставки и обновления строк.
Свойство непротиворечивости ограничений затруднительно оценить количественно. Вероятно, речь должна идти о качественном показателе или комплексе количественных и качественных показателей, позволяющих оценить степень изолированности самих ограничений друг от друга, степень доступности данных, с которыми связано множество ограничений и триггеров, а также долю противоречивых ограничений во всей БД.
3.5. Сложность реализации требования целостности. Даже простые ограничения могут быть реализованы с помощью триггеров. Теоретически это допустимо, но на практике подобные решения снижают эффективность системы [5]. Кроме того, очевидно, что они затрудняют последующую верификацию БД, увеличивают время анализа, так как приходится восстанавливать декларативный смысл каждого триггера. Декларативный смысл обычного ограничения целостности всегда ясен из его описания.
Сложность реализации требования целостности - качественный показатель, оцениваемый для каждого триггера. Если данное требование может быть полностью реализовано при помощи стандартных ограничений, сложность является очень высокой. В противном случае вычисление показателя производится на основе семантического анализа команд, выполняемых в теле триггера. Возможные значения показателя сложности реализации: «очень низкая», «низкая», «средняя», «высокая», «очень высокая».
2.3 Программная корректность баз данных
Корректность программных процедур существенно зависит от их топологической и информационной сложности: чем выше сложность, тем больше вероятность появления неумышленных НДВ, с одной стороны, и тем сильнее усложняется обнаружение любых НДВ, с другой стороны.
К настоящему времени предложено множество метрик оценивания сложности программ [6]. Оценивание сложности хранимых подпрограмм БД может производиться с использованием метрик размера программ и метрик сложности потока управления.
Наиболее распространённой на практике метрикой оценивания размера программ является метрика Холстеда, включающая следующие характеристики:
• словарь операторов п1 - число уникальных операторов программы;
• словарь операндов п2 - число уникальных операндов программы;
• общее число операторов программы N\;
• общее число операндов программы N2.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
Характеристики щ и п2 в сумме составляют словарь программы п, а м и N2 - длину программы N. На основе перечисленных базовых характеристик рассчитывается объём программы, измеряемый в логических единицах информации (символах, операторах, операндах):
V = N • log2 п.
Дополнительно в модели Холстеда вводится характеристика п* -теоретический словарь программы, т. е. словарь, необходимый для написания программы с учётом того, что программа сводится к вызову ранее реализованной функции. Теоретический словарь используется при расчёте потенциального объёма программы:
V = п • log2 п .
Метрики сложности потока управления базируются на представлении программы в виде ориентированного графа G = (V, E), в котором V -множество вершин, соответствующих операторам, E - множество дуг, отражающих переходы между операторами. Для оценивания хранимых подпрограмм БД достаточно применения метрики Маккейба (цикломатического числа Маккейба), характеризующей трудоёмкость тестирования. Цикломатическое число рассчитывается по формуле:
Z(G) = e - v + 2p,
где e - количество дуг графа G; v - количество вершин; p - число компонентов связности графа.
Дополнительно можно использовать метрику Джилба. В ней логическая сложность программы оценивается содержанием в исходном коде операторов ветвления. В рамках метрики Джилба определены следующие характеристики:
• абсолютная сложность - количество операторов условия;
• относительная сложность - отношение числа операторов условия к общему числу операторов программы.
Названные метрики удобно применять при оценивании сложности каждой хранимой подпрограммы в отдельности. Для оценивания сложности программной составляющей БД в целом предлагается использовать показатели сложности объектно-ориентированных программ [7]. Изначально они создавались как характеристики методов программного класса. Так как базам данных присуще свойство инкапсуляции, хранимые подпрограммы можно рассматривать как аналогию методов программного класса в объектно-ориентированной
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
281
программе, а элементы данных БД (атрибуты таблиц) выступают при этом аналогами полей класса.
Исходя из сказанного, можно определить следующие характеристики программной сложности БД.
1. Суммарная сложность подпрограмм БД. Вычисляется как алгебраическая сумма сложностей (весов) всех подпрограмм. С тем, какой именно показатель (из перечисленных выше) будет характеризовать сложность отдельно взятой подпрограммы, необходимо определиться заранее, до выполнения вычислений.
2. Группа показателей, отражающая наличие сцепления между подпрограммами. Сцепление подпрограмм имеет место в том случае, если они используют общие атрибуты таблиц. Малое сцепление в программном классе или компоненте желательно, поскольку оно увеличивает инкапсуляцию и снижает вероятность возникновения ошибок в поведении компонента. Наиболее простым показателем сцепления является разность между числом пар несцепленных и числом пар сцепленных подпрограмм. Отрицательный показатель сцепления всегда приравнивается к нулю.
3 Принципы построения автоматизированной системы проведения верификации реляционных баз данных Microsoft SQL Server
Анализ имеющихся программных систем тестирования баз данных показывает, что в основном их функции ограничены:
• проверкой содержимого таблиц и некоторых ограничений целостности;
• исследованием производительности всей серверной части ИС (включая среду СУБД) во время работы в многопользовательском режиме.
Предлагаемая к рассмотрению в настоящей работе автоматизированная система проведения верификации (АСПВ) БД создаётся с целью обеспечения комплексной проверки корректности БД с учётом их двойственной природы, раскрытой выше.
Основными задачами АСПВ являются следующие.
1. Расчёт показателей корректности исследуемой БД.
2. Собственно верификация, включающая две подзадачи.
2.1. Доказательство того, что в базе данных реализованы все возможности, заявленные в спецификации.
2.2. Выявление элементов НДВ в базе данных и доказательство их принадлежности к уже известному классу, что позволяет исключить ненужные исследования НДВ и ускоряет процесс оценивания корректности базы данных.
3. Изучение новых способов реализации функциональных возможностей, в том числе новых видов НДВ. Включает три подзадачи.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
3.1. Спецификация - построение концептуальной модели функциональной возможности.
3.2. Создание программного образа функциональной возможности по концептуальной модели.
3.3. Алгоритмический анализ, включающий исследование воздействия данной функциональной возможности на СУБД, ОС, вычислительную среду, а также механизмы маскировки НДВ в данной среде.
Для решения всех поставленных задач в АСПВ, очевидно, должно быть предусмотрено обучение на основе использования нейронных сетей. В конечном итоге результатом обучения является программная модель функциональной возможности, которая хранится в базе знаний АСПВ. Система должна уметь распознавать известные ей программные элементы БД и генерировать их описания на основе семантического анализа.
Отдельно следует сказать об используемом языке спецификации. В качестве такового предлагается использовать RSL (RAISE Specification Language) [8]. Аббревиатура RAISE означает Rigorous Approach to Industrial Software Engineering (дословно «строгий подход к разработке промышленного программного обеспечения»). RSL служит для описания свойств и поведения систем и является декларативным языком: он описывает соотношение между входными и выходными данными программы, подпрограммы, операции, но не содержит средств описания алгоритмов.
Важной особенностью логики RSL является использование выражений chaos с целью обозначения непредсказуемого (хаотичного) поведения систем. БД представляет собой развивающуюся систему: работа той или иной хранимой подпрограммы может породить в той же БД новые свойства (вплоть до изменения схемы) и, не исключено, даже новые функции. Отсюда возможность появления новых состояний и нового поведения БД, которые не являются заранее известными, причем RSL-спецификация позволяет отразить это в концептуальной модели.
Основываясь на сказанном выше, можно сформулировать следующие принципы построения АСПВ.
1. АСПВ декомпозируется на подсистемы анализа и синтеза (см. схему). Подсистема анализа включает два модуля:
• модуль предварительного анализа базы данных, предназначенный для выявления элементов НДВ;
• модуль анализа НДВ, отвечающий за алгоритмический анализ выявленной НДВ.
Синтез НДВ объединяет в себе процедуры создания концептуальной и логической моделей НДВ, о которых говорилось ранее.
ISSN 1815-588 X. Известия ПГУПС 2008/1
Общетехнические и социальные проблемы
283
Схема взаимодействия подсистем АСПВ БД
2. Принцип интеллектуализации. Возможность самообучения АСПВ требует наличия баз знаний. Предполагается, что одна база знаний в системе будет хранить описания способов реализации наиболее типичных функций и требований целостности; отдельная база знаний будет содержать элементы НДВ в виде программных моделей и соответствующих им описаний RSL; кроме того, предусматривается использование в системе базы знаний по способам и методам организации сред СУБД и ОС.
Существенную роль в интеллектуальных системах играет автоматизация построения задач исследования, в рассматриваемом случае - анализа и синтеза. Это говорит о том, что в состав подсистем АСПВ должны входить по меньшей мере три следующих блока:
• спецификатор задач анализа, предназначенный для согласования цели исследования с установленным для АСПВ набором типовых задач;
• построитель задач, который на основе наборов типовых задач, выдаваемых спецификатором, конструирует программу анализа;
• блок принятия решений, который с помощью исследователя координирует работу всей подсистемы анализа в соответствии с целями исследования и промежуточными результатами.
Необходимо заметить, что под типовой задачей в описании спецификатора понималась конкретная процедура исследования, позволяющая получать некоторый частный результат.
Приведённый перечень блоков не является полным и будет уточняться в дальнейшем процессе проектирования и разработки АСПВ.
Предполагается, что разрабатываемая АСПВ будет работать с реляционными базами данных, до сих пор имеющими достаточно широкое распространение. Исследование функциональной части, связанное с анализом SQL-кодов, потребует адаптации системы к соответствующему
ISSN 1815-588 X. Известия ПГУПС 2008/1
О84щетехнические и социальные проблемы
диалекту SQL. На начальном этапе предполагается ориентация системы на СУБД Microsoft SQL Server и диалект Transact-SQL. Возможность верификации постреляционных баз данных и, соответственно, взаимодействия с СУБД Oracle, DB2 и т. п. рассматривается как одна из наиболее вероятных перспектив развития системы.
Заключение
Верификация баз данных имеет большое практическое значение, поскольку во многих случаях именно база данных берёт на себя функции ядра ИС, совмещая в себе данные и программные процедуры их обработки. Качество ИС напрямую связано с качеством БД, поэтому разработка и развитие автоматизированных систем комплексного автоматизированного оценивания корректности БД повлечёт за собой повышение качества ИС.
Предложенная система показателей корректности БД не является окончательной. Одно из возможных направлений её доработки -добавление характеристик качества постреляционных (объектнореляционных, объектно-ориентированных и других) БД, а также распределённых БД. Помимо универсальных показателей и метрик, могут использоваться показатели, учитывающие специфику конкретной СУБД.
ISSN 1815-588 X. Известия ПГУПС 2008/1
285
Общетехнические и социальные проблемы Библиографический список
1. Недекларированные возможности в программном обеспечении средств
защиты информации / И. А. Колайда. -
http://www.jetinfo.ru/2000/8/3/article3.8.2000.html.
2. Системы баз данных. Полный курс / Гарсиа-Молина Г., Ульман Дж., Уидом Дж.; пер. с англ. - М. : Вильямс, 2004. - 1088 с. - ISBN 5-8459-0384-X.
3. Обеспечение качества программных средств. Методы и стандарты / В. В. Липаев. - М. : СИНТЕГ, 2001. - 380 с. - ISBN 5-89638-044-5.
4. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг, А. Страчан. - М. : Вильямс, 2000. - 1111 с. - ISBN 5-8459-0109-X.
5. Microsoft ® SQL Server 2000 / Е. В. Мамаев. - СПб. : БХВ-Петербург, 2004. -1280 с. - ISBN 5-94157-025-2.
6. Начала науки о программах / М. Х. Холстед. - М. : Финансы и статистика, 1981. - 128 с.
7. Анализ программного обеспечения с использованием объектноориентированных метрик. Обзор метрик / В. Ю. Романов. http://master.cmc.msu.ru/romanov/russian/pub/OOMetrics-Report.htm.
8. Формальная спецификация программ на языке RSL / Е. А. Кузьменкова. - М. : МГУ, 2001. - 107 с. - ISBN 5-89407-104-6.
УДК 621.892.09 Е. В. Самойлова
ПРИСАДКИ И СПОСОБЫ СМАЗЫВАНИЯ ПАР ТРЕНИЯ
Рассмотрены компаундированные (легированные) масла, схема компаундирования масел, модификаторы вязкости, депрессанты, действие присадок, их классификация, а также способы смазывания пар трения.
смазочные материалы, присадки, пары трения, способы смазывания.
Введение
Существуют две полярные точки зрения. В соответствии с одной из них предлагается внедрять смазочные материалы по следующим причинам:
во-первых, применение смазочных материалов обычно существенно уменьшает коэффициенты и силы трения в подвижных сопряжениях;
во-вторых, в зоне трения при наличии смазки снижается температура, что позволяет осуществлять более длительную и надёжную эксплуатацию механической системы, которая не будет подвержена частым отказам по
ISSN 1815-588 X. Известия ПГУПС 2008/1
