Шаг разработки 2

Информационная система
«Электронный архив»
Шаг разработки 2
© Е. П. Моргунов
1. Основные задачи
1. Разработать базовый вариант интерфейса пользователя.
2. Протестировать созданный вариант программного продукта путем практического
применения, введя 200–300 библиографических описаний в базу данных.
Предполагаемый срок завершения шага 2 – 1 сентября 2007 г.
2. Реализуемые и учитываемые требования
Реализуемые требования – это такие требования, которые на данном шаге разработки
выполняются целиком и полностью, не требуют каких-либо дополнительных доработок на
последующих шагах, т. е. могут считаться завершенной частью работы.
Учитываемые требования – это такие требования, которые на данном шаге разработки
принимаются к сведению, и разработка проводится с учетом их положений и рекомендаций,
однако при этом такое требование не является полностью выполненным (исчерпанным).
2.1. Реализуемые требования
Пользовательские требования (см. документ-концепцию):
– ПФТ1. Соответствие требованиям ГОСТ 7.1–2003;
– ПФТ2. Ввод библиографических описаний в базу данных в готовом виде;
– ПФТ4. Фиксирование результатов проработки источников;
– ПФТ5. Хранение выписок из проработанных источников (п. 1);
– ПФТ6. Система ключевых слов (п. 1);
– ПФТ8. Учет экземпляров;
– ПФТ9. Формирование тематических библиографических списков;
– ПНТ2. Конфигурирование программного продукта (пп. 1, 2, 3);
– ПНТ3. Аутентификация пользователей;
– ПНТ6. Организация коллективной работы (п. 1).
Системные требования (см. архитектуру и системные требования):
– СТ1. Организация доступа пользователя к идентификаторам объектов;
– СТ2. Общая схема организации интерфейса пользователя;
– СТ3. Гибкая схема работы пользователя при вводе данных (пп. 2, 3);
– СТ7. Предоставление полномочий пользователю на уровне отдельных процедур модулей;
1
– СТ8. Проверка полномочий пользователя перед выполнением каждой операции;
– СТ9. Вывод сообщений об ошибках.
2.2. Учитываемые требования
Пользовательские требования (см. документ-концепцию):
– ПФТ3. Обработка наличия различных вариантов имен собственных.
3. Проектирование
1. Алгоритм определения наличия у пользователей прав на выполнение ими конкретных процедур в конкретных модулях.
Используются две административные таблицы базы данных (приведены их определения на языке SQL):
-- ---------------------------------------------------------------------------- Таблица "Пользователи"
-- --------------------------------------------------------------------------CREATE TABLE Users
( user_name text,
-- Имя пользователя
user_description text,
-- Описание пользователя
user_active bool DEFAULT 'no',
-- Флаг активизации пользователя
-- служебная информация
who_chg text DEFAULT USER,
-- Кем добавлена (изменена) запись
when_chg timestamp
DEFAULT CURRENT_TIMESTAMP,
-- Когда добавлена (изменена) запись
PRIMARY KEY ( user_name )
);
-- ---------------------------------------------------------------------------- Таблица "Права доступа"
-- --------------------------------------------------------------------------CREATE TABLE Access
( user_name text,
-- Имя пользователя
module_name text DEFAULT 'ALL', -- Условное наименование модуля
proc_name text DEFAULT 'ALL',
-- Условное наименование процедуры
oper_active bool DEFAULT 'no',
-- Флаг активизации данной операции
-- служебная информация
who_chg text DEFAULT USER,
-- Кем добавлена (изменена) запись
when_chg timestamp
DEFAULT CURRENT_TIMESTAMP,
-- Когда добавлена (изменена) запись
PRIMARY KEY ( user_name, module_name, proc_name ),
FOREIGN KEY ( user_name )
REFERENCES Users ( user_name )
ON DELETE CASCADE
ON UPDATE CASCADE
);
В таблице Access в поля module_name и proc_name могут быть введены значения
«ALL», означающие ВСЕ модули или ВСЕ процедуры. Это может быть удобно для запрета
(или разрешения), например, операции удаления записей во всех модулях или запрета выполнения всех процедур в конкретном модуле.
2
Параметры, которые получает процедура, реализующая данный алгоритм:
– USER_NAME – имя пользователя, для которого выполняется проверка наличия прав
на выполнение указанной процедуры в указанном модуле;
– MODULE – условное наименование модуля;
– PROCEDURE – условное наименование процедуры.
Символом # обозначены комментарии.
Алгоритм определения наличия прав пользователя с именем USER_NAME на выполнение процедуры с именем PROCEDURE в модуле MODULE.
ПОЛУЧИТЬ значения параметров процедуры
ВЫБРАТЬ ЗАПИСИ из таблицы Users по условию user_name = USER_NAME
ЕСЛИ записей нет
ВОЗВРАТИТЬ «ложь»
КОНЕЦ ЕСЛИ
# полномочий для выполнения процедуры нет
ЕСЛИ поле user_active = «ложь»
ВОЗВРАТИТЬ «ложь»
КОНЕЦ ЕСЛИ
# полномочий для выполнения процедуры нет
ВЫБРАТЬ ЗАПИСИ из таблицы Access по условию user_name = USER_NAME
ЕСЛИ записей нет
ВОЗВРАТИТЬ «ложь»
КОНЕЦ ЕСЛИ
# полномочий для выполнения процедуры нет
ЦИКЛ ПОКА есть записи в выборке
ФОРМИРОВАТЬ двухуровневый хеш-массив со структурой
module_name => proc_name => oper_active
КОНЕЦ ЦИКЛА
# При назначении прав доступа локальное решение имеет приоритет над глобальным.
# Например, если для конкретной процедуры конкретного модуля указано, что ее
# выполнение запрещено, а для условного модуля с именем «ALL» указано, что
# выполнение этой процедуры разрешено, то доступа к этой процедуре данный пользователь
# получить не должен.
# последующие проверки выполняются на основе хеш-массива
ЕСЛИ существует запись, у которой proc_name = PROCEDURE и module_name = MODULE
ЕСЛИ поле oper_active = «истина»
ВОЗВРАТИТЬ «истина» # полномочия для выполнения процедуры есть
ИНАЧЕ
ВОЗВРАТИТЬ «ложь»
# полномочий для выполнения процедуры нет
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
ЕСЛИ существует запись, у которой proc_name = PROCEDURE и module_name = «ALL»
ЕСЛИ поле oper_active = «истина»
3
ВОЗВРАТИТЬ «истина»
ИНАЧЕ
ВОЗВРАТИТЬ «ложь»
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
# полномочия для выполнения процедуры есть
# полномочий для выполнения процедуры нет
ЕСЛИ существует запись, у которой proc_name = «ALL» и module_name = MODULE
ЕСЛИ поле oper_active = «истина»
ВОЗВРАТИТЬ «истина» # полномочия для выполнения процедуры есть
ИНАЧЕ
ВОЗВРАТИТЬ «ложь»
# полномочий для выполнения процедуры нет
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
ЕСЛИ существует запись, у которой proc_name = «ALL» и module_name = «ALL»
ЕСЛИ поле oper_active = «истина»
ВОЗВРАТИТЬ «истина» # полномочия для выполнения процедуры есть
ИНАЧЕ
ВОЗВРАТИТЬ «ложь»
# полномочий для выполнения процедуры нет
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
ВОЗВРАТИТЬ «ложь»
# полномочий для выполнения процедуры нет
4. Реализация
Особенностью реализации является то, что библиотека функций (процедур) реализована в форме модуля (пакета) Perl с именем E_ARCH.pm. В этом модуле собраны процедуры,
к которым обращаются все остальные модули программного продукта. В библиотеку, в частности, входят процедуры ввода записей в базу данных, корректировки и удаления записей.
5. Тестирование
Методы тестирования были очень простыми (примитивными) по следующей причине:
разработчиком и пользователем программного продукта является одно и то же лицо. Более
тщательное тестирование отложено на последующие шаги разработки.
Тестирование показало пригодность программного продукта для решения поставленных задач.
6. Эксплуатационная документация
6.1. Руководство пользователя
Не оформлялось.
4
6.2. Руководство программиста
Не оформлялось.
6.3. Руководства по инсталляции и конфигурированию
Не оформлялись.
7. Версия программного продукта
Принято решение присвоить этой версии программного продукта номер 0.2.
Дистрибутивный комплект не формировался.
8. Глоссарий и список сокращений
8.1. Глоссарий
8.2. Список сокращений
БД – база данных
ПНТ – пользовательское нефункциональное требование
ПФТ – пользовательское функциональное требование
СТ – системное требование
СУБД – система управления базами данных
5