Болотская Методическое пособие по выполнению лабораторных 2010
.pdf2.6.Пользователь работает в счете с данными
Вряде случаев более адекватна ситуации другая точка зрения на разделение счетов: программный счет сделать базовым, общим, а счета с данными – индивидуальными, пользовательскими. В этом случае данные должны быть более динамичными, но и более однородными в разных счетах. Это значит, что в разных счетах обрабатываются файлы с одними и теми же именами, с идентичными атрибутами.
Например, в случае использования CASE-технологии для проектирования приложений каждый счет с данными – отдельный проект, который ведет конкретный разработчик или группа разработчиков. Программный счет в этом случае – поддержка единой методологии проектирования с конкретной программной реализацией.
Рабочими счетами являются счета данных. В MD этих счетов, которые в этом случае должны быть полноценными, должны находиться ссылки (Q-указатели) на словари программного счета и на используемые программы (т.е. программы должны быть каталогизированы в счетах данных).
Обязательно должны быть определены одна или несколько рабочих таблиц. Рабочие таблицы необходимы для хранения самых разнообразных списков, промежуточных записей, которые, наверняка, потребуются в процессе функционирования системы. При этом постоянные списки и другие записи многократного использования следует хранить в словарях, а рабочие фрагменты текущего сеанса – в области данных. В этом нет слишком глубокого смысла, это просто добровольные соглашения, которые, однако, способствуют взаимопониманию разработчиков.
Именно так предлагается разделять счета в генераторе приложений SB+. Еще раз отметим, что в этом случае вся работа пользователей осуществляется в счетах с данными.
2.7.Пользователь работает в специальном счете
Внастоящее время очень популярной становится трехуровневая структура, при которой наряду с общим счетом с данными, общим
21
программным счетом, выделяются специальные рабочие счета для пользователей.
Говорят, что это придает максимальную гибкость системе. К слову, D3 предоставляет среду для создания n-уровневых приложений.
На практике могут встретиться самые разнообразные варианты. Мы рассмотрели более или менее подробно два противоположных. Каждый случай уникален! Для того и учат разработчиков, чтобы они принимали грамотные решения в конкретных ситуациях.
2.8.Встроенные средства разработки D3
Квстроенным средствам разработки прикладных систем D3 следует отнести:
•UPDATE-процессор;
•ACCESS-процессор;
•OUTPUT-процессор;
•процессор меню;
•макропроцессор;
•Flash-Basic.
Это то, что имеем, устанавливая D3. Для использования этих средств не надо покупать никаких дополнительных лицензий. Все эти процессоры написаны на виртуальном ассемблере и работают весьма эффективно. С помощью них можно создавать довольно серьезные приложения, однако они будут иметь следующие ограничения:
1)символьный экранный интерфейс (эти средства не приспособлены для работы в графическом интерфейсе);
2)довольно архаичный клавиатурный интерфейс (это ограничение можно в значительной степени преодолеть, перекодируя поток от клавиатуры либо аппаратурно, либо программно).
Поэтому встроенные средства целесообразно применять для бы-
строго прототипирования приложений, используя Flash-Basic для склеивания отдельных частей приложения, придания ему вида единого процесса. Flash-Basic также необходим для реализации отклика на нажатие функциональных клавиш. Разрабатывать приложения на одном Flash-Basic не рекомендуется: это доро-
22
го, а результата, отвечающего современным требованиям, получить все равно не удастся.
Современный подход к реализации прикладных систем – так называемое событийное программирование. Создается некая среда, которая «чувствует» определенные события в системе и позволяет разработчику откликнуться на эти события. Таким образом, устроены все языки уровня 4GL, в частности мощнейший генераторинтерпретатор кода SB+, таким же образом устроен Visual Basic от Microsoft. Однако все они требуют покупки лицензии.
Единственным встроенным процессором, который позволяет реагировать на некоторые события в прикладной системе, является UPDATE-процессор.
Какие же события отслеживает UPDATE -процессор?
1.Событие считывания записи из файла. Точка входа для про-
граммной реакции: input-conversion FDI.
2.Событие сохранения записи в файле. Точка входа для программной реакции: correlative FDI.
3.Событие нажатия функциональной (горячей) клавиши в поле
ввода. Точка входа для программной реакции: hotkeys FDI,ADI.
Это нечто вполне осязаемое. Следовательно, в основе прототипирования прикладной системы встроенными средствами разработки должен лежать UPDATE-процессор. Весьма существенен также тот факт, что UPDATE-процессор работает как процессор данных, используя атрибуты для ссылок на данные. Это определяет в значительной степени декларативный характер разработки, обеспечивая уникальные возможности для модификации и модернизации приложений, ибо всю семантику можно заложить в определения атрибутов.
2.9.Проектирование структур файлов
СУБД D3 предоставляет чрезвычайно гибкие средства для представления информации. На средних объемах файлов (порядка нескольких тысяч записей) ошибки в физических структурах файлов не особенно заметны для потребителей. Тем не менее настоятельно рекомендуется тщательно продумать структуру своих данных и
23
зафиксировать свое представление о ней в так называемой ERдиаграмме или диаграмме классов.
Отображение построенной логической структуры данных в реальные файлы D3 можно выполнить десятками способов. D3 все стерпит и будет работать! Но прежде чем принимать конкретные решения, постарайтесь ответить на следующие вопросы.
1.D3 позволяет хранить записи любой длины и практически любой сложности. Очень часто в реальных системах приходится видеть записи с очень большим количеством полей, что, однако, не вызвано необходимостью. Если запись содержит десятки полей, практически, наверняка, их можно разнести по нескольким файлам.
Очень важно понимать, что с точки зрения просмотра и печати данных словарная система D3 позволяет видеть данные в любых разрезах, независимо от того, где они реально находятся. Для пользователя это всегда один файл. С точки же зрения ввода и корректировки данных желательно, чтобы один экран вводакорректировки по крайней мере в незаполненном состоянии не превышал физических размеров экрана.
Обычно запись файла представляет некоторый объект информационной системы, а поля – свойства этого объекта. Разделить свойства объекта по семантической близости и разнести их по записям разных файлов, используя один и тот же идентификатор объекта (ключ записи) – дело вполне естественное и оправданное.
Итак, чем оправдывается необходимость «сотни» полей в структуре записи физического файла?
2.Файлы данных ни в коем случае не должны содержать никаких полей, служащих оформительским целям. Все оформительские детали экранов ввода, отчетов должны храниться в словарях файлов.
Итак, все ли поля данных действительно информативны?
3.Любое поле файла данных может быть закомментировано! Но все комментарии должны быть вынесены в специальный файл и не должны храниться вместе с основными данными. Более того, некоторые поля текстового характера, вроде бы являющиеся основными, целесообразно оформлять как комментарии.
Например, поле для атрибута «Название_Объекта» можно оставить в основной структуре, а поле для атрибута «Описание_Объекта» лучше оформить как комментарий к названию, или еще как-нибудь, но удалить из основного файла.
24
Итак, все ли текстовые поля действительно необходимо иметь в основной структуре? Нельзя ли их оформить как комментарии?
4.Первое поле в записи – самое доступное. Это истина! Поля, по которым наиболее часто производится выборка записей, которые чаще используются для вывода и т.д., должны быть первыми полями в записи (входить в первую десятку). Поиск и выборка возможны по любому полю, но по первым полям они более эффективны, особенно, если нет индекса. Создание индексов по отдаленным полям существенно убыстряет поиск по ним.
Итак, продуман ли порядок расположения полей в записи?
5.Значения полей по возможности должны быть стандартизованы. Плохо, когда в одной записи стоит «Пушкин А.С.», в другой – «Ал.Серг.Пушкин», а в третьей – «Пушкин Александр Сергеевич»
ит.д. Предпочтительно использование системных справочниковкодификаторов, определенных как стандарты для отрасли, для страны, как международные стандарты.
Итак, определились ли с кодировочными справочниками? Разумеется, этим не исчерпываются все вопросы анализа струк-
тур файлов. Конкретные ситуации ставят конкретные вопросы. Не страшно, если не учли мелких деталей, важно не делать грубых ошибок.
2.10. Моделирование процессов «вручную»
Все процессы обработки данных, которые будут связаны непосредственно с основными таблицами изсчетовс данными(т.е. именно с базой данных), должны выполняться UPDATE-, ACCESS- и OUTPUT- процессорами и проходить исключительно наатрибутном уровне.
Удерживайте себя от соблазна обрабатывать непосредственно физические поля с помощью процедур Flash-Basic. Если не согласны с этим тезисом, то лучше сразу работать с Visual Basic от Microsoft и библиотеками ODBC или RPC (Win32), по крайней мере хоть получите графический интерфейс. Дальнейшее чтение этого разделацелесообразновтомслучае, еслисогласныс этимтезисом!
Прежде всего, необходимо промоделировать все процессы обработки данных «вручную» на уровне TCL. Создайте необходимое множество атрибутов. Для ввода данных запишите соответствую-
25
щие UPDATE-утверждения. Для простейшего вывода – ACCESS- утверждения, в частности для вывода в файл используйте глагол reformat. Проведите все необходимые сортировки, поиск, сравнения, работая со списками. Для более рафинированного вывода используйте OUTPUT-процессор.
Выполняя все это, работайте с базовыми, фундаментальными средствами D3. Они должны работать абсолютно надежно. Если на установке эти средства работают ненадежно, то переходить к различным надстройкам вообще не имеет никакого смысла.
Далее следует уяснить уровень «настраиваемости» приложения, который от нас, как от разработчика, ожидают. Должно ли приложение настраиваться на группы пользователей, а степень его вариабельности быть в пределах каждой группы? Для этого надо понять технологию работы с данными каждой группы и т.д. В конце концов, все сводится к различным сортировкам и вариациям атрибутного состава экранов ввода-корректировки и отчетов. Именно для того, чтобы обеспечить «настраиваемость» приложения, необходимо выйти на уровень Flash-Basic.
Мы говорим о технологии разработки путем создания прототипов. Это обычная практика разработок «изнутри», когда в организации имеется отдел разработки и эксплуатации информационной системы. В этом случае не пишут громоздких постановок, чаще всего их вообще нет. Приложение «притирается» в процессе эксплуатации к реальным потребностям путем перманентной модернизации. Можно считать это этапом постановки задачи. После того, как приложение «притрется», можно говорить о более тщательном перепрограммировании его. Правда, реально этоосуществляетсяочень редко.
2.11. Сохранение и восстановление базы
Как сохранить разработанную базу данных? Мы находимся в разработанном нами счете (базе данных) D3, например с именем «Sklad». Требуется сохранить базу данных «Sklad» на носителе, внешнем по отношению к D3, например на нашей флешке.
Исторически сложилось так, что внешними носителями для D3 считаются ленты. При установке СУБД D3 на нашем компьютере в выбранном нами месте была создана папка D3, в которой находится
26
папка D3Virtual. Именно в файл pseudo0.d3p этой папки, моделирующий ленту, и будет выгружаться наш счет.
Перед началом сохранения счета рекомендуется удалить файл, pseudo0.d3p, так как он, возможно, содержит ранее сохраненные счета и наш счет будет записан в хвост ленты.
Для сохранения счета «Sklad» требуется выполнить следующие действия:
Выполняемая команда |
Комментарий |
|
|
:to dm |
Переход в счет dm ! |
|
|
:set-device 2 |
Происходит |
захват |
файла |
|
pseudo0.d3p. |
Если такого |
файла |
|
нет в папке D3Virtual, то он созда- |
||
|
ется |
|
|
:t-rew |
«Лента» подматывается в начало |
|
|
:account-save Sklad |
Счет Sklad записывается в файл |
||
|
pseudo0.d3p |
|
|
:t-det |
Файл pseudo0.d3p освобождается и |
||
|
может быть скопирован на флешку. Для |
||
|
выхода из D3 рекомендуется выполнить |
||
|
команду shutdown |
|
|
Как восстановить разработанную базу данных? Наша база данных (счет) «Sklad» находится на внешнем носителе (флешке)
в виде файла windows pseudo0.d3p.
Чтобы восстановить базу данных в D3, необходимо выполнить следующие действия:
Выполняемая команда |
Комментарий |
|
|
Средствами windows скопиро- |
Если в папке D3Virtual. уже есть |
||
вать файл pseudo0.d3p в папку |
файл с таким именем, его надо пере- |
||
D3Virtual |
именовать или удалить |
|
|
:to dm |
Переход в счет dm ! |
|
|
:set-device 2 |
Происходит |
захват |
файла |
|
pseudo0.d3p |
|
|
:t-rew |
«Лента» подматывается в начало |
||
:account-restore Sklad |
Счет Sklad восстанавливается |
||
:t-det |
Файл pseudo0.d3p освобождается |
||
:to Sklad |
Переход в счет «Sklad» |
|
|
|
27 |
|
|
3.Лабораторныйпрактикум
3.1.Лабораторная работа 1. Разработка базы данных многопользовательской системы
При подготовке к лабораторной работе 1 требуется разработать концептуальную модель предметной области, для которой создается многопользовательская система. Так как база данных системы должна поддерживаться СУБД с многозначной моделью данных, то концептуальную модель предметной области лучше представлять в виде диаграммы классов, хотя можно использовать и ERдиаграммы.
В процессе выполнения лабораторной работы на основе концептуальной модели предметной области должна быть разработана схема базы данных. Составляющие элементы схемы базы данных в СУБД D3 хранятся в словарях файлов, в так называемых записях описания файлов (File Defining Item – FDI) и записях описа-
ния атрибутов (Attribute Defining Item – ADI). Существен-
но, что схема базы данных в СУБД D3 играет не предписывающую, как в реляционных СУБД, а описывающую роль. Это значит, что одни и те же данные могут быть описаны многократно, т.е. существовать несколько схем, в соответствии с которыми будут обрабатываться данные, хранимые в областях данных.
Существенной особенностью систем, построенных с использованием СУБД D3, является широкое использование виртуальных атрибутов. Фактически это оригинальный способ использования встроенных процедур. Для создания виртуальных атрибутов используются так называемые коды обработки. СУБД D3 предоставляет большое число встроенных кодов, которые применяются в атрибутах для выполнения типовых операций обработки, а для какойлибо оригинальной обработки с помощью языка FlashBasic программист может написать свой собственный код. Заметим, что виртуальные атрибуты, хотя и привязаны к конкретному файлу базы данных, фактически могут получаться путем обработки данных многих файлов. При этом эти атрибуты имеют все права, что и ат-
28
рибуты, отражающие непосредственное значение поля некоторой записи.
Создание схемы базы данных предполагает:
•создание файлов;
•указание способа формирования ключей записей файлов;
•создание триггеров, реагирующих на изменение записей файлов, в частности мосты, связывающие файлы, – один из способов создания триггеров;
•определение атрибутов файлов;
•декларацию ассоциаций атрибутов файла.
Создание схемы базы данных продемонстрируем на примере разработки базы данных для предметной области «Мониторинг чемпионата России по футболу». На рис. 3.1 и 3.2 показаны предельно упрощенная модель предметной области и схема базы данных. Модель предметной области представлена в стиле диаграммы классов, причем виртуальные (вычисляемые) свойства представлены как методы. Схема базы данных приведена в виде модифицированной диаграммы классов, что определяется особенностями реализации базы под управлением СУБД D3.
СУБД D3 предоставляет очень простые средства для прототипирования систем. Фактически можно построить вполне работоспособный прототип информационной системы, практически не прибегая к программированию.
В представленной на рисунках модели предметной области и соответствующей схеме базы количество виртуальных (вычисляемых) свойств (атрибутов) значительно больше числа реально существующих полей в записях файлов. Прототипирование информационной системы сводится к разработке вычисляемых атрибутов с последующем использованием системных процессоров UPDATE и ACCESS, соответственно, для модификации базы данных и составления различных отчетов. Именно так построена система «Футбольный чемпионат», подобные системы предстоит построить в ходе выполнения лабораторных работ.
Базу данных составляют два файла «Team» и «Play».
29
Команда |
|
2 |
1 |
Игра |
|
«Play» |
|
ID |
|||
ID |
|
|
|||
Название |
|
|
Хозяин |
||
Игры дома (M) |
|
|
Гость |
||
Игры в гостях (M) |
|
|
Забил хозяин |
||
|
|
|
|
Забил гость |
|
Количество Игр дома |
|
|
|
|
|
|
|
|
|
||
Счет дома (M) |
|
|
|
|
|
Очки дома (M) |
|
|
|
|
|
Количество Игр в гостях |
|
|
|
|
|
Счет в гостях (M) |
|
|
|
|
|
Очки в гостях (M) |
|
|
|
|
|
Количество Игр |
|
|
|
|
|
Мячи |
|
|
|
|
|
Очки |
|
|
|
|
|
Рис. 3.1. Модель предметной области
Team |
Команда |
bTeam;2;3 |
Play |
Игра |
|
1 |
ID_Team |
|
1 ID_Play |
||
2 |
TeamName |
Название |
|
2 t1 |
Хозяин |
3 |
plD |
Игры дома (M) |
bTeam;3;4 |
3 t2 |
Гость |
4 |
plG |
Игры в гостях |
|
4 z1 |
Забил хозяи |
|
|
(M) |
|
5 z2 |
Забил гость |
2 |
PlayD |
Количество игр |
|
|
|
2 |
SochD |
дома |
|
|
|
Очки дома |
|
|
|
||
2 |
GdD |
Мячи дома |
|
|
|
2 |
PlayG |
Количество игр |
|
|
|
2 |
SochG |
в гостях |
|
|
|
Очки в гостях |
|
|
|
||
2 |
GdG |
Мячи в гостях |
|
|
|
2 |
SochW |
Очки общие |
|
|
|
2 |
GdW |
Мячи общие |
|
|
|
2 |
PlayW |
ИгрW |
|
|
|
3 |
chD |
Счет дома (M) |
|
|
|
3 |
ochD |
Очки дома (M) |
|
|
|
4 |
chG |
Счет в гостях (M) |
|
|
|
4 |
ochD |
Очки в гостях (M) |
|
|
|
|
|
|
|
|
|
Рис. 3.2. Схема базы данных. Класс «Команда» представлен файлом D3 «Team», а класс «Игра» – файлом «Play»
30