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

«Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ...»
Г.Н. Калянов

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

Предметно-ориентированная программная оболочка

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

В последние годы развиваются современные программные продукты, такие, как FoxPro, Delphi и т.д., которые призваны решать проблемы пользователя самим пользователем, более того, разработаны целые методики создания адаптируемых систем которые «повернуты лицом» к пользователю. Современное направление - CASE-технологии - призвано дать возможность проектирования программных систем без участия профессиональных разработчиков. Порой для программных CASE-продуктов выпускается специальное электронное оборудование. Примером может служить широко известный интерпретатор JAVA для которого фирма-разработчик SUN производит как JAVA-серверы, так и JAVA-станции. Этот язык, который широко используется для написания приложений в InterNet, предназначен для обработки, обмена и представления различного рода информации. Известно, что разработчику сложно получить исчерпывающую информацию для оценки требований к системе, он сталкивается с чрезмерным количеством разнородных сведений о предметной области, что затрудняет общее понимание задачи. Перспективным видится подход, при котором в процессе создании прикладного программного продукта максимально используются знания пользователя в сочетании с умением программиста. Для этого необходимо дать пользователю инструментальное программное средство, максимально приближенное по используемой системе понятий, интерфейсу, квалификации функциональных модулей к его предметной области. В данной статье предлагается один из подходов к решению проблемы - гибкая расширяемая система (ГРС), которая должна удовлетворять как конечного пользователя, так и разработчика программных продуктов.

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

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

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

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

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

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

Определение элементов данных в словаре

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

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

CASE-средства различных компаний предоставляют для разработчиков возможность работы со словарями данных. Значительно упрощают работу графические средства, реализующие диаграммы потоков данных - DFD (Data Flow Diagrams) и диаграммы «сущность-связь» ERD(Entity-Relationship Diagrams). Например, Oracle Corporation создала группу CASE-продуктов, таких, как Case*Dictionary, Case*Designer, Case*Generator, позволяющих не только модифицировать и документировать все этапы разработки системы, но и моделировать процессы и потоки данных в системе. Так, Case*Dictionary управляет хранилищем информации, создаваемой и используемой другими средствами Oracle CASE. Case*Designer имеет различные средства, моделирующие, в частности, потоки данных и процессы с помощью графических инструментальных средств DFD и ERD. Вся информация из Case*Designer автоматически регистрируется Case*Dictionary и сохраняется в ее центральном хранилище. Case*Generator автоматически генерирует внутреннюю базу данных, интерфейсные приложения работы с формами и отчетами, превращая, таким образом, проект в реальную систему.

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

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

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

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

Определение 1

Хранилищем будем называть файл, предназначенный для хранения данных системы, имеющих стандартный формат таблицы, характеризующийся постоянной структурой. Формат записи: «имя хранилища».

Определение 2

Атрибутом хранилища назовем атрибут таблицы (поле). Формат записи: «имя хранилища».»название поля».

Определение 3

Дугой будем называть направленную связь между двумя хранилищами. Формат записи: "имя хранилища"-"имя хранилища".

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

Определение 4

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

Определение 5

Вторичные данные - данные хранилищ, получаемые в процессе обработки первичных данных.

Определение 6

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

Под нулевым набором D0 будем понимать первичные данные. Если есть (n-1)-й набор Dn-1, то Dn получается из него применением n-го процесса.

Исходя из этих определений, можно построить граф, узлы которого - хранилища (см. рис. 1).

Рис.1.

ik - k-й набор хранилищ.

Обозначим атрибуты хранилищ как узлы графа, тогда получим ациклический граф атрибутов (см.рис. 2). Это объясняется тем, что замкнутый процесс перехода атрибута dikjn в самого себя недопустим. Полученный граф назовем А-графом.

Рис.2.

dikjn - jn - n-й атрибут, ik - ого хранилища.

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

1) группу внешних данных;

2) данные, которые в процессе эксплуатации системы не изменяются -справочные (справочники);

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

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

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

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

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

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

Построение реляционной модели словаря предметно-ориентированной оболочки

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

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

Для описания потоков данных на уровне хранилищ, необходимо хранить информацию, описывающую граф (см. рис. 1), т.е. таблица «Граф хранилищ» должна иметь ссылку на таблицу «Список хранилищ», а также содержать информацию о направлении потока данных. Исходя из структуры таблицы 1, достаточно хранить код первичного и вторичного хранилищ.

Замечание

Подробное описание построения индексов и обоснование этого построения будет дано при введении операций над словарем.

Для описания потоков данных на уровне атрибутов необходимо хранить информацию, описывающую А-граф (рис. 2). Таблица «Граф атрибутов» должна иметь ссылку на таблицу «Список атрибутов хранилищ» и содержать информацию о направлении потока данных. Исходя из структуры таблицы 2, достаточно хранить код первичного и вторичного атрибутов.

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

Организация словаря данных осуществляется с помощью графического пользовательского интерфейса. Визуальное представление в виде диаграмм потоков данных и диаграммы «сущность-связь» осуществляется только для администраторов системы с помощью прикладных пакетов типа «ERwin». Реализация данной концепции словаря данных будет осуществляться с помощью СУБД FoxPro 2.6 for Windows 3.1 и выше и СУБД FoxPro 5.0 for Windows 95, а также Windows NT 3.5 и выше.

Литература

1. Бобровски С. Oracle 7 вычисления клиент/сервер М.: «Лори», 1996.

2. Калянов Г.Н. CASE структурный системный анализ. М.:, «Лори», 1996.

3. Козлинский А.В. CASE-технология: индустриальная разработка систем обработки информации // Компьютерное обозрение. 1993 №1 С.29-40

4. Липаев В.В. Управление разработкой программных комплексов. М.: Финансы и статистика, 1993

5. Фокс Д. Программное обеспечение и его разработка. М.: Мир, 1985.