Проектирование Интернет-библиотеки

1 2

---

Содержание

Введение 3 1 Проектная часть 5 1.1 Формулировка предметной задачи 5 1.2. Анализ требований к программе 6 1.3. Функциональная модель системы. 9 1.4. Концептуальная модель данных системы. 39 2. Программная реализация проекта. 42 2.1. Выбор языка и других программных средств релизации. 42 2.2 Описание логической модели базы данных 48 2.3 Описание реализации программы 50 Заключение 53 Список использованных источников 54

Введение

В век развития информационных технологий автоматизация любых процессов, начиная от производственных задач, и заканчивая элементами индустрии развлечений, прочно вошла в обиход. Причины такого явления просты – автоматизировав ту или иную задачу с помощью вычислительной техники, можно переложить на технику наиболее нудные и наиболее сложные операции, требующих значительных трудовых и временных затрат либо из-за продолжительности времени их выполнения, либо из-за высокой сложности их производства (например, научные вычисления). Помимо прочего, автоматизация большого числа процессов выгодна экономически. Дешевле, а во многих случаях значительно дешевле закупить оборудования и программное обеспечение, наладив автоматизированный процесс, чем держать для выполнения задач большой штат сотрудников. В рамках данной курсовой работы рассматривается автоматизация процессов работы библиотеки путём создания электронного библиотечного ресурса. Содержание библиотеки в бумажном виде требует отдельных помещений, специалистов по хранению книг и сотрудников, работающих с читателями и каталогами. Всё это влечёт за собой расходы, которые, как показывает практика, не окупаются. Замена бумажной библиотеки на электронную поможет решить этот и другие недостатки существующей модели. Целью настоящего исследования является разработка проекта информационной системы Интернет-библиотеки. Информационная система интернет-библиотека предназначена для удаленного доступа к литературным произведениям. Чтение литературы происходит в online режиме, что позволяет отказаться от необходимости локального хранения файлов с содержимым книг у читателей. Соединение с библиотекой происходит посредством сети Интернет, что делает информацию достуной по всему миру. Основной задачей, поставленной перед Интернет-библиотекой является обеспечение доступа к литературной информации на стороне сервера, с разделение прав на модификацию и чтение материла. Исследование будем проводить согласно следующему плану: • собрать и проанализировать требования к проекту; • сформулировать задачу в терминах предметной области; • провести формализацию поставленной задачи; • провести проектирование информационной системы; • создать прототип, иллюстрирующий работу системы. В качестве результатов, получаемых по завершении каждого из этапов будут получены следующие документы: • список требований, описание среды ИС, ограничения на разработку; • задача, сформулированная в терминах предметной области; • формулировка основных концепций и архитектуры модели; • реализованный интерактивный прототип системы; В целом проект является весьма актуальным с экономической точки зрения для библиотечной организации – отсутствие затрат на аренду помещений, сокращение штата персонала, для удобства читателей – возможность чтения любимой книги, не выходя из дома.

1 Проектная часть

1.1 Формулировка предметной задачи

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

1.2. Анализ требований к программе

По реультатам предыдущего этапа – сбора требований возможно выделить основые функции системы, участников взаимодействия и примерный набор инфомационных данных, которые в ней циркулируют. Рассмотрим требования к функционалу системы со стороны пользователей. На рис. 2 приведена диаграмма вариантов использования (use-case) системы. Согласно диаграмме в системе будет выделено 3 вида пользователей. Наименьший набор прав у незарегистрированнного пользователя. Согласно требованиям такой пользователь не имеет доступа к литературе. В рамках системы незарегистрированный пользователь имеет доступ только к функции регистрации. После регистрации пользователь приобретает статус Читатель. Пользователь типа Читатель является основным участником системы. Такой пользователь имеет возможность начать работу с системой (войти в систему) и закончить работу(выйти из системы). Для реализации основной своей потребности Читатель использует функции выбора нужной книги и получения доступа к чтению текста описаний и текста выбранной книги. При выборе книги из списка читатель реализует функцию получения описания. Рисунок 2 Диаграмма use-case Интернет-библиотека Функциональная роль администратора – выполнение действий по обеспечению работы библиотеки. Администратор добавляет новые книги, сопровождая их кратким описанием. По требованию правообладателя администратор должен удалить текст литературы и описания из базы. Также администратор имеет возможноть блокирования (удаления) аккаунтов недобросовестных пользователей. Еще одной важной особенностью администратора является его право на добавление пользователя в группу администраторов, т.е. наделение особыми правами в системе. Сгруппируем требования к системе, выделенные ранее в основные функциональные группы:  Процессы по обеспечению идентификации пользователя:  регистрация;  авторизация.  Процессы обслуживание читателя:  предоставление списка доступной литературы;  предоставление описаний литературы;  предоставления доступа к чтению литературы.  Процессы администрирования:  добавление книги;  удаление книги;  редактирование/добавление описания книги;  редактирование списка читателей/администраторов. Затем выделим внешние по отношению к системе сущности:  незарегистрированный пользователь;  читатель;  администратор. Идентифицируем информацию, которая циркулирует в системе. На этапе регистрации пользователь передает в систему данные необходимые для регистрации: • Логин, пароль – обязательные поля, необходимые для идентификации пользователя, определения принадлежности к группе, определения прав. • Фамилия, имя, отчество – необходимы для формирования обращения к пользователю в тексте письма, формирования приветствия в тексте веб-интерфейса. Поля не обязательны к заполнению. • Адрес, телефон – контактные данные пользователя. По указанным контактным данным будет сообщено о новых поступлениях литературы. Для идентификации пользователя достаточно данных обязательных полей регистрации – логина и пароля. В процессе использования читательского интерфейса задействованы следующие данные: • список доступных на сервере книг; • выбор пользователя из списка; • описание (аннотация книги); • текст книги. В процессе использования интерфейса администратора: • тексты новых книг; • тексты кратких описаний книг (аннотации); • данные об удаляемых книгах; • данные о добавлении пользователя в группу; • данные об удалении пользователя из группы; В результате обращения к каждой из операций системы формируется отчет о выполнении. В отчете содержится информация об успешности выполнения действий или инфомация об ошибках.

1.3. Функциональная модель системы

Данных, собранных на предшествующих этапах, достаточно для составления предварительных модельных диаграмм. При описании функциональной модели системы будем использовать диаграммы потоков данных (DFD), совместно с мини-спецификациями для описания процессов. Диграммы потоков данных являются основным средством моделирования функциональных требований проектируемой системы. С их помощью требования разбиваются на функциональные компоненты и представляются в виде сети, связанной потоками данных .[1, стр. 17]. Приведем описание основных элементов DFD в соответствие с учебником Г.Н. Калянова [1]. На диаграммах DFD основные функциональные требования к системе выражаются в виде процессов и хранилищ, связанных потоками данных. Потоки данных предназначены для моделирования передачи информации между различными частями системы. Потоки на диаграммах обозначаются стрелками, ориентированными в сторону движения потока. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Хранилище (накопитель) данных позволяет определить данные, которые будут сохраняться в памяти между процессами. Имя хранилища должно идентифицировать его содержимое. Далее приведем содержимое диаграмм потоков данных, описывающих функционирование Интернет-библиотеки. Картинки с диаграммами потоков будут поясняться в текстовом описании на естественном языке. Контекстная диаграмма Рисунок 3 Контекстная диаграмма Контекстная диаграмма моделирует функционирование системы в наиболее общем виде. На контекстной диаграмме отражено взаимодействие системы с окружением, т.е. с внешними сущностями. На контекстной диаграмме описываются потоки информации, которые система получает и отправляет внешним сущностям. Таким образом на контекстной диаграмме определен интерфейс взаимодействия системы с внешним миром. В системе предусмотрено 3 типа внешних сущностей, с которыми система взаимодействует: • незарегистрированный пользователь; • читатель; • администратор. Все перечисленные внешние сущности являются пользователями системы. Рассмотрим взаимодействия в системе с точки зрения каждого из типов пользоватей. Незарегистрированный пользователь. При взаимодействии с системой незарегистрированный пользователь имеет возможность использования только функции регистрации в системе. Процесс регистрации проходит путем заполнения полей в форме регистрации. В форме регистрации обязательными полями являются логин и пароль, необязательные к заполнению поля – Фамилия, Имя, Отчество, Адрес, Телефон. После заполнения полей формы, пользователь инициирует передачу информации нажатием на кнопку подтверждения регистрации. Затем информация обрабатывается и сохраняется в системе. Рассмотрим подробнее состав информации, необходимой для регистрации пользователя в системе. Логин – обязательное поле, требуемое для идентификации пользователя в системе.Логин являвляется идентификатором, на основании которого система определяет принадлежность к группам, проверяет права доступа к функциям системы. Логин должен быть уникальным в рамках системы, т.е. в системе не должно быть двух пользователей группы с одинаковым логином. Логин должен состоять из букв латинского алфавита и цифр. Длина логина должна быть не менее 3 символов и не должна превышать 20 символов. Пароль необходим для подтверждения принадлежности логина пользователю. Пароль должен отвечать требованиям безопасности, чтобы было труднее подобрать пароль методом полного перебора и перебора по словарю. Пароль должен содержать буквы нижнего и верхнего регистра, должен содержать цифры. Предъявляются требования к минимальной длине пароля. Минимальная длина пароля – 5 символов. Максимальная длина пароля 20 символов. Другие дополнительные сведения необходимы для связи с читателем. Фамилия, Имя, Отчество – необходимы для обращения к пользователю по телефону, в тексте письма, для формирования обращения в тексте веб-интерфейса. Адрес и телефон нужны в качестве контактных данных, для сообщения пользователям данных о новым поступлениях, отправки сообщений по интересным пользователям темам. В ответ на запрос регистрации пользователя система отправляет отчет об успешной регистрации в случае соблюдения всех условий или сообщение об ошибке в противном случае. После прохождения регистрации пользователь получает статус читателя. Читатель. Каждому читателю сопоставлен набор идентификационных данных – логин, пароль. Используя идентификационные данные, пользователь получает доступ к основным функциям системы. Для получения доступа к основным фунциям системы пользователь вводит логин и пароль в соответсвующие поля системы. В случае некорректных данных пользователь получает отказ, на экран выводится сообщение об ошибке. Если данные введедены верно пользователь получает доступ к системе. Система отправляет пользователю список доступной литературы. Пользователь имеет возможность отсеять литературу по жанру. Получив список литературы, пользователь выбирает нужную ему книгу, системе передается идентификатор выбранной книги (номер книги в списке). В ответ от системы поступают описания книг, и текст книги. Администратор. Администратор должен выполнять действия, направленные на поддержание и обеспечение основной деятельности системы. Для реализации такой деятельности администратор имеет доступ к ряду дополнительных возможностей системы – добавлению новой литературы, удалению литературы, редактированию состава пользовательских групп – читателей, администраторов. Используя веб-интерфейс, администратор отправляет в систему необходимые данные о добавляемых/удаляемых пользователях, отправляет тексты новых книг и описаний, данные об удаляемых книгах. В ответ система выводит отчеты о выполненных действиях. Диаграммы декомпозиции Рисунок 4 Диаграмма декомпозиции первого уровня На диаграмме декомпозиции (см. рис. 4) более подробно расписаны основные фунции системы и распределение потоков информации по функциональным блокам. На диаграмме декомпозиции 1-го уровня функции системы разделены на 4 типа: • процессы регистрации пользователя; • процессы идентификации пользователя; • процессы обработки действий читателя; • процессы обработки действий администратора. На диаграмме также изображены хранилища данных системы, в которых хранятся необходимые для идентификации сведения (хранилище данных читателей, хранилище данных администраторов) и данные непосредственно литературы – тексты книг и описания (хранилище книг и описаний). Рассмотрим подробнее каждый из указанных функциональных блоков диаграммы. Для создания учетной записи читателя предназначен процесс «Зарегистрировать читателя». В качестве входных потоков передается информация полей регистрационной формы – логин, пароль, дополнительные идентификационные данные – фамилия, имя, отчество, адрес, телефон. Информация о читателе записывается в хранилище данных о читателях. Пользователю вовращается сообщение об успехе регистрации или сообщение об ошибке. В ходе процесса «Идентифицировать пользователя» происходит сопоставление пользователя уникальному в контексте системы идентификатору. В данном случае в роли идентификатора выступает логин. Проверяется подлинность идентификации пользователя посредством введенного пароля. На основе идентификатора – логина происходит присвоение прав пользователю на выполнение функций в системе (авторизация). Процесс «Обработать запрос читателя» включает в себя набор читательских функций системы. На вход его поступают данные о необходимой пользователю литературе, на выходе система выдает тексты и описания запрошенной литературы, списки доступной литературы и т.д. Процесс «Обработать запрос на администрирование» включает в себя процессы, направленные на выполнение функций по администрированию системы. На вход процесса поступают необходимые данные для выполнения команд, тексты и описания добавляемых книг. В ответ система выполняет заданные действия и отправляет пользователю отчеты о проведенных операциях. Рисунок 5 Зарегистрировать читателя На рис. 5 приведена диаграмма декомпозиции процесса «Зарегистрировать читателя». На вход данного процесса подаются потоки данных, собранных с формы регистрации. Процессы-составляющие можно разделить на две группы. Процессы первой группы направлены на обработку, проверку и приведение к предусмотренному в системе хранения формату данных. Суть данных процессов сводится к предварительной обработке данных. Процессы второй группы направлены на формирование и выполнение запросов к базе данных зарегистрированных пользователей. Опишем немного подробнее сущность процессов диаграммы декомпозиции. Процесс «Проверка корректности логина» направлен на контроль соблюдения заданных требований к логину. Логин является идентификатором в системе, потому он должен быть уникальным. Логин должен содержать буквы латинского алфавита, цифры. В случае несоблюдения требований к логину процесс регистрации прекращается и пользователю система отправляет сообщение об ошибке (отказ в регистрации). Проверяется также и пароль (процесс «Проверка корректности пароля»), введенный пользователем при регистрации. Необходимо не допустить небезопасные варианты пароля, которые легко подобрать перебором по словарю или методами полного перебора. Особенно актуальны требования по сложности пароля для пользователей группы администраторов. В случае несоблюдения требований к сложности пароля процесс регистрации прекращается и пользователю система отправляет сообщение об ошибке (отказ в регистрации). В состав дополнительных сведений включены поля необязательные для заполнения в форме регистрации – фамилия, имя, отчество, адрес, телефон. Дополнительные сведения приводятся к необходимому формату – проверяются и обрабатываются пустые поля, обрабатываются поля телефонного номера (процесс «Обработка дополнительных сведений»). На состав дополнительных требований не накладывается никаких требований. Если поля дополнительных сведений заполнены некорректно, содержимое их отбрасывается. Все полученные в ходе обработки данные поступают на вход процесса, в результате которого будет сформирован и совершен запрос к базе данных в корректном формате. В результате выполнения запроса сведения о регистрации пользователя будут сохранены в хранилище. Рисунок 6 Идентифицировать пользователя На рис. 6 приведена диаграмма декомпозиции процесса «Идентифицировать пользователя». В процессе идентификации проверяются данные, введенные пользователем в web-форме входа в систему. Из базы данных запрашивается набор данных о зарегистрированных пользователях (процессы «Запросить из БД идентификационные данные читателей», «Запросить из БД идентификационные данные администраторов»). Введенный пользователем идентификатор проверяется на присутствие в базе зарегистрированных читателей и администраторов. Проверяется соответствие логина и пароля (процессы «Проверка идентификации читателя», «Проверка идентификации администратора»). Если идентификатор не был найден в базе или же введенный пароль не соответсвует паролю в базе, то пользователю будет отказано во входе в систему и отправлено сообщение об ошибке. Рисунок 7 Обработать запросы читателя На рис.7 изображена диаграмма декомпозиции процесс «Обработать запросы читателя». Перед началом началом обработки запроса на литературу проверяется наличие у пользователя прав на чтение литературы (процесс «Проверить право на чтение»). Проверка права на чтение происходит путем проверки вхождения логина пользователя в состав группы читателей. После подтверждения права пользователя на чтение, ему предоставляется выбор из списка жанров, доступных в системе. Читатель производит выбор жанра литературы (процесс «Выбор жанра литературы»). В ответ система предоставляет список доступной литературы и описания для заданного жанра, пользователь из предоставленного списка выбирает книгу (процесс «Выбрать книгу из списка»). В ответ система предоставляет текст указанной книги для чтения. (процесс «Отправить пользователю текст книги). Рисунок 8 Обработать запрос на администрирование На рис. 8 представлена диаграмма декомпозиции процесса «Обработать запрос на администрирование». В состав процессов вошли функции системы, направленные на реализацию деятельности администратора. Перед выполнением каждого из действий происходит проверка на наличие необходимых прав на выполнение (процесс «Проверить права на выполнение»). Авторизация пользователя на выполнения действий административного характера происходит на основе наличия логина пользователя в списке администратов. На вход процесса «Добавить книгу» от администратора поступают все необходимые для добавления данные – тексты книг и их описания. После проверок и выполнения процесса система посылает в базу данных запрос на добавление. Если при добавлении произошла ошибка пользователю отправляется отчет об ошибке. На вход процесса «Удалить книгу» поступают идетификаторы книг, которые необходимо удалить. На выходе же система посылает запрос на удаление книг и описаний из базы данных. Если произошла ошибка в процессе удаления или нет прав на удаление, пользователю система отправляет отчет об ошибке. Процессы «Добавить/удалить читателя», «Добавить/удалить администратора» предназначены для внесения изменений в состав списка читателей, администраторов. На вход процесса поступают данные, необходимые для добавления пользователя – логин, пароль (см. диаграмму Зарегистрировать пользователя А1), для удаления достаточно идентификатора – логина. Также на вход процесса из хранилища поступают данные обо всех зарегистрированных в системе читателях, администраторах. При возникновении ошибки пользователь получит от системы отчет об ошибке. Рисунок 9 Проверка корректности логина На рис. 9 изображена диаграмма декомпозиции для процесса «Проверка корректности логина». Целью данного процесса является проверка данных о логине, которые пользователь ввел при регистрации. Предложенный пользователем логин проходит ряд проверок на соответствие внутренним требованиям системы. Проверенный логин передается на выход процесса. Если проверка логина на одном из этапов проверки оканчивается неудачей, процесс прерывается, и на выход процесса отправляется сообщение об ошибке – некорректном логине. Данные о логине проверяются на наличие недопустимых символов, что равноценно проверке на наличие только символов заданного допустимого алфавита символов (процесс «Проверить на отсутствие недопустимых символов»). На выходе процесса получаем логин из набора допустимых символов. После чего данные передаются на вход процесса «Проверка длины». Длина логина должна быть не менее заданного минимального значения, не должна превышать максимального значения. После прохождения проверки на длину, логин проверяется на уникальность в процессе «Проверить на уникальность». Логин читателя должен быть уникальным в контексте базы читателей. Для проверки уникальности на вход подается список логинов зарегистрированных читателей из базы данных. По прохождению всех проверок данные о логине, проверенные на корректность передаются на выход процесса «Проверка корректности логина». Рисунок 10 Проверка корректности пароля На рис. 10 приведена диаграмма декомпозиции процесса «Проверка корректности пароля». Целью процесса является проверка предложенного пользователем пароля на соответствие требованиям системы. На вход процесса подается пароль, введенный пользователем в форму регистрации. Пароль проходит серию проверок. После проверенный пароль передается на выход процесса. Если на одном из этапов проверки пароль не удовлетворяет поставленным требованиям, процесс прерывавается, и на выход процесса передается сообщение о некорректном пароле. Сначала проверяется длина пароля (процесс «Проверить длину»). Значение длины пароля должно быть больше минимального значения и меньше максимального значения. Пароль с допустимым значением длины передается на вход процесса «Проверить отсутствие недопустимых символов». Суть данного процесса состоит в проверке каждого символа пароля на вхождение в заданный алфавит допустимых символов. После проверки пароля на допустимость символов пароль проверяется на наличие цифровых символов и символов верхнего регистра. Требование наличия цифровых символов и символов верхнего регистра введены из соображений безопасности.(процессы «Проверить наличие цифровых символов», «Проверить наличие символов верхнего регистра»). Рисунок 11 Добавить книгу На рис. 11 приведена диаграмма декомпозиции процесса «Добавить книгу». Целью процесса является добавление новой книги в базу доступной для читателя литературы. На вход процесса подаются текст книги, описание книги и права на добавление книги. Сначала проверяется наличие прав на добавление (процесс «Проверка права на добавление») – права на добавление есть у членов группы администраторы. Если права на добавление отсутствуют, то процесс прерывается, и в отчете передается сообщение об ошибке. Далее происходит проверка книги на наличие в базе загруженных (процесс «Проверка на дубликат»). На вход процесса подаются данные о книгах, хранящихся в базе. Если книга уже присутствует в базе, то процесс прерывается и на выход отправляется сообщение об ошибке. Иначе формируется запрос на добавление текста книги и ее описания в базу хранимых книг (процесс «Запросить добавления текста и описания в базу»). После совершения запроса на выход отправляется отчет об успешном добавлении книги в базу. Рисунок 12 Удалить книгу На рис. 12 изображена диаграмма декомпозиции процесса «Удалить книгу». Процесс предназначен для удаления книги, сохраненной в базе. На вход процесса поступает поток с данными о правах на удаление, данные о хранимых в базе книгах и идентификаторы книг, которые необходимо удалить. На выходе процесса поток с отчетом о выполнении операции. Проведение действий по удалению книги доступно только пользователям из группы администраторов. Проверка на наличие прав происходит в процессе «Проверить права на удаление книги». Данные о подтверждении прав поступают на вход процесса «Запросить удаление книг и описаний из базы». При отсутствии прав на удаление процесс прерывается и на выход подается отчет об ошибке удаления. Для удаления книги необходимо убедиться в наличии идентификатора книги в базе (процесс «Проверить на наличие книги в базе»). После необходимых проверок производится запрос на удаление книги и описания из базы (процесс «Запросить удаление книг и описаний из базы»). Рисунок 13 Добавить/удалить администратора На рис. 13 изображена диаграмма декомпозиции процесса «Добавить/удалить администратора». В составе процессы по обеспечению функций по удалению и добавлению пользователей в группу администраторов. Процессы добавления администратора: Производится проверка наличия права на добавление – процесс «Проверить права на добавление администратора», подтверждение передается в процесс «Добавить администратора». При отсутствиии права на добавление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа. На вход процесса «Добавить администратора» подаются данные о добавляемом администраторе, сведения о содержимом базы администраторов и подтверждение права на добавление администратора. На выходе процесса получаем отчет об успехе или ошибке добавления. Процессы удаления администратора: Производится проверка наличия права на удаление – процесс «Проверить права на удаление администратора», подтверждение передается в процесс «Удалить администратора». При отсутствиии права на удаление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа. На вход процесса «Удалить администратора» подаются данные об удаляемом администраторе, сведения о содержимом базы администраторов и подтверждение права на удаление администратора. На выходе процесса получаем отчет об успехе или ошибке удаления. Рисунок 14 Добавить/удалить читателя На рис. 14 изображена диаграмма декомпозиции процесса «Добавить/удалить читателя». В составе процессы по обеспечению функций по удалению и добавлению пользователей в группу читателей. Процессы добавления читателя: Производится проверка наличия права на добавление – процесс «Проверить права на добавление читателя», подтверждение передается в процесс «Добавить читателя». При отсутствиии права на добавление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа. На вход процесса «Добавить читателя» подаются данные о добавляемом читателе, сведения о содержимом базы читателей и подтверждение права на добавление читателя. На выходе процесса получаем отчет об успехе или ошибке добавления. Процессы удаления читателя: Производится проверка наличия права на удаление – процесс «Проверить права на удаление читателя», подтверждение передается в процесс «Удалить читателя». При отсутствиии права на удаление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа. На вход процесса «Удалить читателя» подаются данные об удаляемом читателе, сведения о содержимом базы читателей и подтверждение права на удаление читателя. На выходе процесса получаем отчет об успехе или ошибке удаления. В технологии структурного анализа для описания процессов нижнего уровня применяют миниспецификации. В своей работе [3] Вендров отмечает, что «миниспецификация является конечной вершиной иерархии ДПД». Миниспецификация призвана описать процессы диаграмм нижнего уровня декомпозиции со степенью детализации достаточной для реализации кода программы. Миниспецификации являются основой для кодогенерации. В составе спецификации необходимо указать номер (название) процесса, список входных и выходных потоков, приводится описание тела процесса. Для задания тела процесса используется несколько методов от структурированного естественного языка до визуальных форм (FLOW-формы, диаграммы Насси-Шнейдермана). Приведем миниспецификации для процессов на диаграмме декомпозиции процесса «Проверка корректности пароля». (см. диаграмма A11 на рис. 9). Спецификация процесса «Проверить на отсутствие недопустимых символов» (процесс 1 на диаграмме A11). @ВХОД = Логин @ВЫХОД = Логин без недопустимых символов, некорретный логин @СПЕЦПРОЦ A11.1 Проверить на отсутствие недопустимых символов Рисунок 15 Проверка корректности логина Спецификация процесса «Проверка длины» (процесс 2 на диаграмме A11). @ВХОД = Логин без недопустимых символов @ВЫХОД = Логин допустимой длины, некорретный логин @СПЕЦПРОЦ A11.2 Проверка длины Спецификация процесса «Проверить на уникальность» (процесс 3 на диаграмме A11) @ВХОД = Логин допустимой длины @ВЫХОД = Корректный логин @СПЕЦПРОЦ A11.3 Проверить на уникальность Приведем также спецификации процессов для диаграммы декомпозиции процесса «Проверка корректности пароля». Спецификация процесса «Проверить длину» (процесс 1 на диаграмме A12). @ВХОД = Пароль @ВЫХОД = Пароль достаточной длины, некорректный пароль @СПЕЦПРОЦ A12.1 Проверить длину ВЫПОЛНИТЬ Разбить пароль на последовательность символов ВЫПОЛНИТЬ Определить длину последовательности ЕСЛИ длина последовательности < мин. значение ТО ВЫПОЛНИТЬ Передать сообщение об ошибке ВЫПОЛНИТЬ Прервать процесс ИНАЧЕ ЕСЛИ длина последовательности > макс. значение ТО ВЫПОЛНИТЬ Передать сообщение об ошибке ВЫПОЛНИТЬ Прервать процесс КОНЕЦЕСЛИ КОНЕЦЕСЛИ ВЫПОЛНИТЬ Передать пароль на выход процесса Спецификация процесса «Проверить отсутствие недопустимых символов» (процесс 2 на диаграмме A12). @ВХОД = Пароль достаточной длины @ВЫХОД = Пароль без недопустимых симоволов,некорректный пароль @СПЕЦПРОЦ A12.2 Проверить отсутствие недопустимых символов ВЫПОЛНИТЬ Разбить пароль на последовательность символов ВЫПОЛНИТЬ Определить длину последовательности пароля ВЫПОЛНИТЬ Обнулить значение счетчика1 ПОКА значение счетчика1 < длины последовательности пароля ВЫПОЛНИТЬ Определить значение длины допустимого алфавита ВЫПОЛНИТЬ Обнулить значение счетчика2 ВЫПОЛНИТЬ Обнулить флаг совпадения ПОКА значение счетчика2 < длины допустимого алфавита ЕСЛИ символ пароля № значение счетчика 1 = символа допустимого алафита № значение счетчика 2 ТО ВЫПОЛНИТЬ флаг совпадения = 1 КОНЕЦЕСЛИ ВЫПОЛНИТЬ Увеличить значение счетчика2 на единицу КОНЕЦПОКА ЕСЛИ флаг совпадения = 0 ТО ВЫПОЛНИТЬ Выдать сообщение об ошибке ВЫПОЛНИТЬ Прервать процесс КОНЕЦЕСЛИ ВЫПОЛНИТЬ Увеличить значение счетчика1 на единицу КОНЕЦПОКА ВЫПОЛНИТЬ Передать пароль на выход процесса Спецификация процесса «Проверить наличие цифровых символов» (процесс 3 на диаграмме A12). @ВХОД Пароль без недопустимых символов @ВЫХОД Пароль с цифрами, некорректный пароль @СПЕЦПРОЦ А12.3 Проверить наличие цифровых символов ВЫПОЛНИТЬ Разбить пароль на последовательность символов ВЫПОЛНИТЬ Определить длину последовательности пароля ВЫПОЛНИТЬ Обнулить значение счетчика1 ВЫПОЛНИТЬ Обнулить флаг цифры ПОКА значение счетчика1 < длины последовательности пароля ВЫПОЛНИТЬ Обнулить значение счетчика2 ПОКА значение счетчика2 < 10 ЕСЛИ символ пароля № счетчик1 = счетчик2 ТО ВЫПОЛНИТЬ флаг цифры = 1 КОНЕЦЕСЛИ ВЫПОЛНИТЬ увеличить значение счетчика2 КОНЕЦПОКА КОНЕЦПОКА ЕСЛИ флаг цифры = 1 ТО ВЫПОЛНИТЬ Передать пароль на выход процесса ИНАЧЕ ВЫПОЛНИТЬ Отправить сообщение об ошибке КОНЕЦЕСЛИ

1.4. Концептуальная модель данных системы

Одним из наиболее популярных средств формализации предметной области являются модели сущность-связь (ERD). Использование ER-диаграмм положено в основу популярных коммерческих CASE-средств, поддерживающих полный цикл разработки базы данных. Моделирование предметной области основано на применении диаграмм в стандартизованной графической нотации. На основе построенной ER-диаграммы затем стоят даталогическую модель для реализации в определенной СУБД. Сущность представляет собой множество объектов, обладающих общими атрибутами, характеристиками. Сущность должна представлять на диаграмме некоторый объект, должна быть уникально идентифицирована. Сущность должна быть именована согласно классу объектов, которая она представляет. Отношение в общем общем виде представляет связь между двумя сущностями, описывает как типы данных взаимосвязаны. «Концептуальная база данных – это абстрактное отображение физической базы данных (или что равносильно, физическая база данных есть реализация концептуальной базы данных), а представления являются абстракциями некоторых частей концептуальной базы данных.» [2, стр. 12]. Из приведенного определения концептуальной базы данных следует, что такой базой называют абстракцию уровня более высокого, чем уровень физического представления и представляемой в виде абстракций объектов предметной области. Для описания концептуальной модели базы данных приведем набор диаграмм сущность — связь. Каждая из приведенных диаграмм соответствует хранилищам данных на диаграммах потоков данных. Изображения диаграмм будем сопровождать кратким текстовым описанием. Рисунок 15 ERD хранилище книг и описаний На рис. 15 приведена концептуальная диаграмма сущность-связь в нотации Чена для хранилища книг и описаний. На диаграмме определены основные информационные сущности — автор, жанр, книга. Для упрощения идентификации в каждую сущность добавлен атрибут уникальной идентификации – ID. Сущность автор содержит хранимую информацию об авторе книги –идентификатор, имя автора. Сущность книга содержит набор данных, значимых для читателя – название, текст книги, описание, год издания. Также книга имеет атрибут идентификации – ID. Сущность жанр имеет атрибуты: название жанра и идентификатор. На диаграмме идентифицированы основные отношения между сущностями, определены кардинальности связей. Рисунок 16 ER-диаграмма хранилище данных читателей На рис. 16 изображена концептуальная модель для хранилища данных читателей. В хранилище данных о читателе содержатся данные о зарегистрированных в системе читателях. Выделено две информационные сущности – читатель, содержащая идентифкационные данные читателя и Профиль, содержащая дополнительную информацию о пользователе. С профилем пользователя может быть ассоциировано несколько наборов идентификационных данных. Рисунок 17 ER-диаграмма хранилища данных администраторов Диаграмма на рис. 17 моделирует предметную область для хранилища данных администраторов. Аналогично диаграмме на рис. 16 данные разделены по двум сущностям – администратор и профиль. Сущность администратор содержит идентификационную информацию. Сущность профиль содержит дополнительную информацию, указанную пользователем при регистрации. С профилем администратора может быть связано несколько наборов идентификационных данных.

---

1 2