Разработка проекта информационной системы Интернет-библиотеки



Содержание

Введение

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

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

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

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

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

Замена бумажной библиотеки на электронную поможет решить этот и другие недостатки существующей модели.

Цельюнастоящего исследования является разработка проекта информационной системы Интернет-библиотеки.

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

Основной задачей, поставленной перед Интернет-библиотекой является обеспечение доступа к литературной информации на стороне сервера, с разделение прав на модификацию и чтение материла.

Исследование будем проводить согласно следующему плану:

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

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

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

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

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

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

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

Рисунок  Интернет-библиотека как черный ящик

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

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

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

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

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

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

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

Рассмотрим требования к функционалу системы со стороны пользователей. На рис. 2 приведена диаграмма вариантов использования (use-case) системы. Согласно диаграмме в системе будет выделено 3 вида пользователей.

Наименьший набор прав унезарегистрированнного пользователя. Согласно требованиям такой пользователь не имеет доступа к литературе. В рамках системы незарегистрированный пользователь имеет доступ только к функции регистрации.

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

Рисунок  Диаграммаuse-case Интернет-библиотека

Функциональная роль администратора – выполнение действий по обеспечению работы библиотеки. Администратор добавляет новые книги, сопровождая их кратким описанием. По требованию правообладателя администратор должен удалить текст литературы и описания из базы. Также администратор имеет возможноть блокирования (удаления) аккаунтов недобросовестных пользователей. Еще одной важной особенностью администратора является его право на добавление пользователя в группу администраторов, т.е. наделение особыми правами в системе.

Сгруппируем требования к системе, выделенные ранее в основные функциональные группы:

Затем выделим внешние по отношению к системе сущности:

Идентифицируем информацию, которая циркулирует в системе.

На этапе регистрации пользователь передает в систему данные необходимые для регистрации:

Для идентификации пользователя достаточно данных обязательных полей регистрации – логина и пароля.

В процессе использования читательского интерфейса задействованы следующие данные:

В процессе использования интерфейса администратора:

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

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

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

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

Приведем описание основных элементовDFD в соответствие с учебником Г.Н. Калянова []. На диаграммахDFD основные функциональные требования к системе выражаются в виде процессов и хранилищ, связанных потоками данных. Потоки данных предназначены для моделирования передачи информации между различными частями системы. Потоки на диаграммах обозначаются стрелками, ориентированными в сторону движения потока. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Хранилище (накопитель) данных позволяет определить данные, которые будут сохраняться в памяти между процессами. Имя хранилища должно идентифицировать его содержимое.

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

Контекстная диаграмма

Рисунок  Контекстная диаграмма

Контекстная диаграмма моделирует функционирование системы в наиболее общем виде. На контекстной диаграмме отражено взаимодействие системы с окружением, т.е. с внешними сущностями. На контекстной диаграмме описываются потоки информации, которые система получает и отправляет внешним сущностям. Таким образом на контекстной диаграмме определен интерфейс взаимодействия системы с внешним миром.

В системе предусмотрено 3 типа внешних сущностей, с которыми система взаимодействует:

Все перечисленные внешние сущности являются пользователями системы. Рассмотрим взаимодействия в системе с точки зрения каждого из типов пользоватей.

Незарегистрированный пользователь. При взаимодействии с системой незарегистрированный пользователь имеет возможность использования только функции регистрации в системе. Процесс регистрации проходит путем заполнения полей в форме регистрации. В форме регистрации обязательными полями являются логин и пароль, необязательные к заполнению поля – Фамилия, Имя, Отчество, Адрес, Телефон. После заполнения полей формы, пользователь инициирует передачу информации нажатием на кнопку подтверждения регистрации. Затем информация обрабатывается и сохраняется в системе.

Рассмотрим подробнее состав информации, необходимой для регистрации пользователя в системе.

Логин – обязательное поле, требуемое для идентификации пользователя в системе.Логин являвляется идентификатором, на основании которого система определяет принадлежность к группам, проверяет права доступа к функциям системы. Логин должен быть уникальным в рамках системы, т.е. в системе не должно быть двух пользователей группы с одинаковым логином. Логин должен состоять из букв латинского алфавита и цифр. Длина логина должна быть не менее 3 символов и не должна превышать 20 символов.

Пароль необходим для подтверждения принадлежности логина пользователю. Пароль должен отвечать требованиям безопасности, чтобы было труднее подобрать пароль методом полного перебора и перебора по словарю. Пароль должен содержать буквы нижнего и верхнего регистра, должен содержать цифры. Предъявляются требования к минимальной длине пароля. Минимальная длина пароля – 5 символов. Максимальная длина пароля 20 символов.

Другие дополнительные сведения необходимы для связи с читателем. Фамилия, Имя, Отчество – необходимы для обращения к пользователю по телефону, в тексте письма, для формирования обращения в тексте веб-интерфейса.

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

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

После прохождения регистрации пользователь получает статус читателя.

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

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

Диаграммы декомпозиции

Рисунок  Диаграмма декомпозиции первого уровня

На диаграмме декомпозиции (см. рис. 4) более подробно расписаны основные фунции системы и распределение потоков информации по функциональным блокам.

На диаграмме декомпозиции 1-го уровня функции системы разделены на 4 типа:

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

Рассмотрим подробнее каждый из указанных функциональных блоков диаграммы.

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

В ходе процесса «Идентифицировать пользователя» происходит сопоставление пользователя уникальному в контексте системы идентификатору. В данном случае в роли идентификатора выступает логин. Проверяется подлинность идентификации пользователя посредством введенного пароля. На основе идентификатора – логина происходит присвоение прав пользователю на выполнение функций в системе (авторизация).

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

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

Рисунок  Зарегистрировать читателя

На рис. 5 приведена диаграмма декомпозиции процесса «Зарегистрировать читателя». На вход данного процесса подаются потоки данных, собранных с формы регистрации. Процессы-составляющие можно разделить на две группы. Процессы первой группы направлены на обработку, проверку и приведение к предусмотренному в системе хранения формату данных. Суть данных процессов сводится к предварительной обработке данных. Процессы второй группы направлены на формирование и выполнение запросов к базе данных зарегистрированных пользователей.

Опишем немного подробнее сущность процессов диаграммы декомпозиции.

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

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

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

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

Рисунок  Идентифицировать пользователя

На рис. 6 приведена диаграмма декомпозиции процесса «Идентифицировать пользователя». В процессе идентификации проверяются данные, введенные пользователем вweb-форме входа в систему. Из базы данных запрашивается набор данных о зарегистрированных пользователях (процессы «Запросить из БД идентификационные данные читателей», «Запросить из БД идентификационные данные администраторов»). Введенный пользователем идентификатор проверяется на присутствие в базе зарегистрированных читателей и администраторов. Проверяется соответствие логина и пароля (процессы «Проверка идентификации читателя», «Проверка идентификации администратора»). Если идентификатор не был найден в базе или же введенный пароль не соответсвует паролю в базе, то пользователю будет отказано во входе в систему и отправлено сообщение об ошибке.

Рисунок  Обработать запросы читателя

На рис.7 изображена диаграмма декомпозиции процесс «Обработать запросы читателя». Перед началом началом обработки запроса на литературу проверяется наличие у пользователя прав на чтение литературы (процесс «Проверить право на чтение»). Проверка права на чтение происходит путем проверки вхождения логина пользователя в состав группы читателей. После подтверждения права пользователя на чтение, ему предоставляется выбор из списка жанров, доступных в системе. Читатель производит выбор жанра литературы (процесс «Выбор жанра литературы»). В ответ система предоставляет список доступной литературы и описания для заданного жанра, пользователь из предоставленного списка выбирает книгу (процесс «Выбрать книгу из списка»). В ответ система предоставляет текст указанной книги для чтения. (процесс «Отправить пользователю текст книги).

Рисунок  Обработать запрос на администрирование

На рис. 8 представлена диаграмма декомпозиции процесса «Обработать запрос на администрирование». В состав процессов вошли функции системы, направленные на реализацию деятельности администратора.

Перед выполнением каждого из действий происходит проверка на наличие необходимых прав на выполнение (процесс «Проверить права на выполнение»). Авторизация пользователя на выполнения действий административного характера происходит на основе наличия логина пользователя в списке администратов.

На вход процесса «Добавить книгу» от администратора поступают все необходимые для добавления данные – тексты книг и их описания. После проверок и выполнения процесса система посылает в базу данных запрос на добавление. Если при добавлении произошла ошибка пользователю отправляется отчет об ошибке.

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

Процессы «Добавить/удалить читателя», «Добавить/удалить администратора» предназначены для внесения изменений в состав списка читателей, администраторов. На вход процесса поступают данные, необходимые для добавления пользователя – логин, пароль (см. диаграмму Зарегистрировать пользователя А1), для удаления достаточно идентификатора – логина. Также на вход процесса из хранилища поступают данные обо всех зарегистрированных в системе читателях, администраторах. При возникновении ошибки пользователь получит от системы отчет об ошибке.

Рисунок  Проверка корректности логина

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

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

По прохождению всех проверок данные о логине, проверенные на корректность передаются на выход процесса «Проверка корректности логина».

Рисунок  Проверка корректности пароля

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

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

Рисунок  Добавить книгу

На рис. 11 приведена диаграмма декомпозиции процесса «Добавить книгу». Целью процесса является добавление новой книги в базу доступной для читателя литературы. На вход процесса подаются текст книги, описание книги и права на добавление книги. Сначала проверяется наличие прав на добавление (процесс «Проверка права на добавление») – права на добавление есть у членов группы администраторы. Если права на добавление отсутствуют, то процесс прерывается, и в отчете передается сообщение об ошибке. Далее происходит проверка книги на наличие в базе загруженных (процесс «Проверка на дубликат»). На вход процесса подаются данные о книгах, хранящихся в базе. Если книга уже присутствует в базе, то процесс прерывается и на выход отправляется сообщение об ошибке. Иначе формируется запрос на добавление текста книги и ее описания в базу хранимых книг (процесс «Запросить добавления текста и описания в базу»). После совершения запроса на выход отправляется отчет об успешном добавлении книги в базу.

Рисунок  Удалить книгу

На рис. 12 изображена диаграмма декомпозиции процесса «Удалить книгу». Процесс предназначен для удаления книги, сохраненной в базе. На вход процесса поступает поток с данными о правах на удаление, данные о хранимых в базе книгах и идентификаторы книг, которые необходимо удалить. На выходе процесса поток с отчетом о выполнении операции. Проведение действий по удалению книги доступно только пользователям из группы администраторов. Проверка на наличие прав происходит в процессе «Проверить права на удаление книги». Данные о подтверждении прав поступают на вход процесса «Запросить удаление книг и описаний из базы». При отсутствии прав на удаление процесс прерывается и на выход подается отчет об ошибке удаления. Для удаления книги необходимо убедиться в наличии идентификатора книги в базе (процесс «Проверить на наличие книги в базе»). После необходимых проверок производится запрос на удаление книги и описания из базы (процесс «Запросить удаление книг и описаний из базы»).

Рисунок  Добавить/удалить администратора

На рис. 13 изображена диаграмма декомпозиции процесса «Добавить/удалить администратора». В составе процессы по обеспечению функций по удалению и добавлению пользователей в группу администраторов.

Процессы добавления администратора:

Производится проверка наличия права на добавление – процесс «Проверить права на добавление администратора», подтверждение передается в процесс «Добавить администратора». При отсутствиии права на добавление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа.

На вход процесса «Добавить администратора» подаются данные о добавляемом администраторе, сведения о содержимом базы администраторов и подтверждение права на добавление администратора. На выходе процесса получаем отчет об успехе или ошибке добавления.

Процессы удаления администратора:

Производится проверка наличия права на удаление  – процесс «Проверить права на удаление администратора», подтверждение передается в процесс «Удалить администратора». При отсутствиии права на удаление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа.

На вход процесса «Удалить администратора» подаются данные об удаляемом администраторе, сведения о содержимом базы администраторов и подтверждение права на удаление администратора. На выходе процесса получаем отчет об успехе или ошибке удаления.

Рисунок  Добавить/удалить читателя

На рис. 14 изображена диаграмма декомпозиции процесса «Добавить/удалить читателя». В составе процессы по обеспечению функций по удалению и добавлению пользователей в группу читателей.

Процессы добавления читателя:

Производится проверка наличия права на добавление – процесс «Проверить права на добавление читателя», подтверждение передается в процесс «Добавить читателя». При отсутствиии права на добавление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа.

На вход процесса «Добавить читателя» подаются данные о добавляемом читателе, сведения о содержимом базы читателей и подтверждение права на добавление читателя. На выходе процесса получаем отчет об успехе или ошибке добавления.

Процессы удаления читателя:

Производится проверка наличия права на удаление  – процесс «Проверить права на удаление читателя», подтверждение передается в процесс «Удалить читателя». При отсутствиии права на удаление процесс прерывается и в отчете на выход передается сообщение об ошибке права доступа.

На вход процесса «Удалить читателя» подаются данные об удаляемом читателе, сведения о содержимом базы читателей и подтверждение права на удаление читателя. На выходе процесса получаем отчет об успехе или ошибке удаления.

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

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

Приведем миниспецификации для процессов на диаграмме декомпозиции процесса «Проверка корректности пароля». (см. диаграммаA11 на рис. 9).

Спецификация процесса «Проверить на отсутствие недопустимых символов» (процесс 1 на диаграммеA11).

@ВХОД = Логин

@ВЫХОД = Логин без недопустимых символов, некорретный логин

@СПЕЦПРОЦA11.1 Проверить на отсутствие недопустимых символов

Рисунок  Проверка корректности логина

Спецификация процесса «Проверка длины» (процесс 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-диаграммы затем стоят даталогическую модель для реализации в определенной СУБД.

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

«Концептуальная база данных – это абстрактное отображение физической базы данных (или что равносильно, физическая база данных есть реализация концептуальной базы данных), а представления являются абстракциями некоторых частей концептуальной базы данных.» [, стр. 12].

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

Для описания концептуальной модели базы данных приведем набор диаграмм сущность - связь. Каждая из приведенных диаграмм соответствует хранилищам данных на диаграммах потоков данных. Изображения диаграмм будем сопровождать кратким текстовым описанием.

РисунокERD хранилище книг и описаний

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

Для упрощения идентификации в каждую сущность добавлен атрибут уникальной идентификации –ID.

Сущность автор содержит хранимую информацию об авторе книги –идентификатор, имя автора.

Сущность книга содержит набор данных, значимых для читателя – название, текст книги, описание, год издания. Также книга имеет атрибут идентификации –ID.

Сущность жанр имеет атрибуты: название жанра и идентификатор.

На диаграмме идентифицированы основные отношения между сущностями, определены кардинальности связей.

Рисунок 6ER-диаграмма хранилище данных читателей

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

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

С профилем пользователя может быть ассоциировано несколько наборов идентификационных данных.

Рисунок 7ER-диаграмма хранилища данных администраторов

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

С профилем администратора может быть связано несколько наборов идентификационных данных.

2. Программная реализация проекта

2.1. Выбор языка и других программных средств релизации

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

Для разработки системы выбран язык Web-программирования PHP.

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

За последние шесть лет экосистема РНР претерпела существенные изменения. До выхода РНР 5 разработчики, создавали свои проекты в основном для разового использования, и каждый из этих проектов отличался индивидуальностью; если новому проекту уделялось достаточно внимания, он оказывался лучше предыдущих — но гарантий не было. Несмотря на наличие средств и способов управления качеством и стандартами кода, они все еще были недостаточно развиты и не находили широкого применения. Идея использования РНР в качестве основы для стабильных приложений корпоративного уровня вызывала лишь насмешки, несмотря на тот факт, что он использовался в некоторых наиболее посещаемых веб-сайтах [].

С выходом РНР 5 разработчики стали уделять больше внимания разработке надежных приемов программирования. Пересмотренная и переработанная объектная модель стала прочной основой для создания объектов, пригодных для многократного использования. Такие программные средства, как PHPUnit, использовали эту объектную модель, чтобы упростить и сделать более надежными подходы к тестированию кода. Это, в свою очередь, привело к более пристальному изучению соответствия качества кода жизненному циклу приложений на РНР.

Именно в этой экосистеме начали появляться РНР-фреймворки. Хотя некоторые из них существовали и для РНР 4, в РНР 5 эта идея приобрела популярность, и в результате начали развиваться несколько фреймворков. Их целью было обеспечить пользователей лучшими решениями и предоставить повторяемую и пригодную к многократному использованию структуру для разрабатываемых приложений [].

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

Разработчики тоже довольны РНР. В исследовании десяти языков сценариев, проведенном в августе 2009 года компанией Evans Data Corporation, наиболее довольные пользователи были выявлены среди разработчиков на РНР (за ними с небольшим отставанием следуют пользователи Ruby и Python). В частности, РНР занял первые места по таким показателям, как кроссплатформенная совместимость, доступность и качество программных средств и производительность, и вторые — за простоту сопровождения и удобочитаемость кола, расширяемость, простоту использования и безопасность.

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

Хотя на первый взгляд это и не очевидно, но хваленая простота использования РНР — одновременно и достоинство, и недостаток. Достоинство заключается в том, что в отличие от, скажем, С++ или Java, программы на РНР относительно легко читать и понимать, и данный факт подталкивает начинающих разработчиков к экспериментам и быстрому освоению языка, минуя стадию кропотливого изучения. Недостаток же в том, что присущее РНР отсутствие «строгости» дает этим разработчикам ложное ощущение безопасности и подталкивает их к написанию общедоступных приложений без понимания необходимых стандартов качества, безопасности и возможности повторного использования кода.

С учетом всего этого в последние несколько лет в рядах PHP-сообщества происходила напряженная и плодотворная работа по переходу от программирования в стиле «можно все» к более стандартизированному подходу, ориентированному на использование фреймворков. Этот подход не только упрощает первоначальную подготовку при написании PHP-приложения с нуля, но и позволяет создавать более ясный, последовательный и безопасный код.

Таким образом,  качестве языка программирования выбран РНР – легкий в освоении язык для быстрой разработки малых и средних Web-приложений. Он позволяет быстро разработать многомодульную программу, в которой каждый модуль отвечает за свою конечную функциональность.

HTML, CSS и JavaScript – три кита, на которых держится разработка современных web-приложений.

HTML – язык разметки web-страниц – предназначен для текстового описания страницы: её элементов, их состава, свойств и расположение.

CSS – Cascade StyleSheet (каскадная таблица стилей) является вспомогательным средством для HTML и предназначен для описания стилей отображения элементов на web-странице.

Вообще говоря, средств HTML и CSS достаточно для того, чтобы полностью описать вид web-страницы. Однако в тех случаях, когда ставится задача «вдохнуть в web-страницу жизнь», запрограммировать её так, чтобы она реагировала на действия пользователя, средств языка разметки оказывается совершенно недостаточно, даже если дополнить его стилями.

Проблема именно в недостаточной интерактивности HTML и CSS. В CSS существует набор приемов, позволяющих управлять стилями в специфических ситуациях, например при наведении указателя мыши на ссылки, но возможности программиста все равно крайне ограничены. Псевдоклассы CSS, такие как hover, link, active и некоторые другие, позволяют изменять стили отдельных участков web-страницы при определенных условиях, однако их недостаточно для создания сколь-нибудь сложных сценариев. А уж для создания анимации и других эффектов, которые часто можно встретить на web-страницах, таблицы стилей и вовсе не предназначены изначально.

Благодаря JavaScript программист может перехватит все происходящие на странице события, например щелчки пользователя на кнопках, изменение размеров окна обозревателя или ввод данных в текстовое поле [].

А так как JavaScript — это язык написания сценариев, можно написать код, отвечающий на действия пользователя, например, выполнением вычислений, динамической заменой изображения или проверкой данных.

Поэтому ещё одной используемой технологией является язык программирования JavaScript.

и сценарии командной строки для UNIX-подобных операционных систем.

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

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

Изменилось все, кроме JavaScript.Инструмент, прежде использовавшийся как средство, позволяющееуменьшить число обращений к серверу, стал применяться все шире.Там, где раньше использовались десятки строк кода на JavaScript, сталиприменяться сценарии, насчитывающие сотни, а порой и тысячи строк. Появление Internet Explorer 4 и динамического HTML (возможности изменять некоторые аспекты страниц без их перезагрузки) давало уверенность, что объем программного кода на языке JavaScript в страницах со временем будет только расти.

Последним крупным шагом в развитии браузеров было появление объектноймодели документа (Document Object Model, DOM), унифицированногоподхода к реализации динамического HTML, выполненной в InternetExplorer 5, Netscape 6 и Opera. Реализации этой модели близкосоответствовали третьей версии стандарта ЕСМА-262. С появлением браузеров,поддерживающих DOM и (более или менее) одну и ту же версиюJavaScript, родилась платформа для веб-приложений. Несмотря на огромныйскачок в развитии и обобщенный API, используемый при созданиисценариев на языке JavaScript, сами реализации JavaScript, выполняющиеэти сценарии, практически не развивались.

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

Первое существенное увеличение производительности интерпретаторы JavaScript получили в 2008 году. Компания Google представила свой, совершенно новый браузер Chrome. Он стал первым браузером, оснащенным оптимизированным интерпретатором JavaScript под кодовым названием V8. Интерпретатор JavaScript V8 включает механизм компиляции во время выполнения (Just-In-Time, JIT), который преобразует программный код на языке JavaScript в машинный код и выполняет его. Это обеспечило чрезвычайно высокую скорость выполнения программного кода JavaScript.

Другие производители браузеров последовали этому примеру и реализовали собственные оптимизированные версии интерпретаторов JavaScript. Браузер Safari 4 был оснащен JIT-интерпретатором JavaScript под названием Squirrel Fish Extreme (иногда его также называют Nitro),a Firefox - интерпретатором TraceMonkey, оптимизирующим часто выполняемые фрагменты программного кода.

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

MySQL — это очень популярная и к тому же бесплатная система управления базами данных (СУБД), разработанная компанией MySQL АВ.

СУБД MySQL является легким и быстрым провайдером баз данных, рассчитанным в первую очередь на работу с интернет-сайтами нижнего и среднего уровня. Отсутствие таких технических возможностей, как блокировка отдельных строк таблицы (исправлено в движке InnoDB) с лихвой компенсируется скоростью работы провайдера – выборка из 10 миллионов строк выполняется менее чем за 1 секунду, а ядро СУБД в случае использования той структуры базы данных, которая приводится в настоящей работе, способно без заметного падения быстродействия обрабатывать запросы более чем от 100 клиентов одновременно.

Наряду с комплектом серверного программного обеспечения, который состоит из PHP, MySQL и JavaScript, в динамической Интертет-технологии фигурирует еще один немаловажный объект веб-сервер. Наилучший выбор – это web-сервер Apache. Выше было немного сказано о том, что входит в круг задач веб-сервера: он играет главную роль в обмене данные между клиентом и сервером по интернет-протоколу HTTP, однако в реальности объём его задач более масштабен [].

К примеру, веб-сервер Apache занимается обслуживанием не только веб-страниц — он работает с большим спектром файлов, начиная с рисунков, фотографий и Flash-роликов и заканчивая музыкальными файлами, файлами RSS-лент (Really Simple Syndication - простое распространение по подписи) и т. д. Для выполнения указанных задач каждый элемент, найденный на веб-странице веб-клиентом, также передаётся через сервер, который затем и осуществляет передачу.

Apache поддерживает также обширный арсенал собственных модулей. В дополнение к модулям РНР наиболее важными для вас как для веб-программиста будут модули, занимающиеся обеспечением безопасности. В качестве других примеров могут послужить модуль Rewrite, позволяющий веб-серверу обрабатывать широкий диапазон типов URL-адресов и перезаписывать их в соответствии с его внутренними требованиями, и модуль Proxy, который можно использовать для обслуживания часто запрашиваемых страниц из кэша, для того чтобы снизить нагрузку на сервер.

2.2 Описание логической модели базы данных

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

Продолжим процесс проектирования модели базы данных, используя диаграммы концептуальной модели, приведенные в разделе 1.4.

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

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

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

Рисунок 8 Внутренняя модель данных

Внутренняя модель данных представлена набором из 8 таблиц.

ТаблицаAuthor содержит информацию об Авторе книги – Имя, Фамилия, Отчество, идентификатор.

ТаблицаBook содержить информацию о книге – название книги, год издания, описание и текст книги, идентификатор книги.

ТаблицаGenre содержит информацию о разделе (жанре) литературы.

ТаблицаBook_author содержит информацию об авторах книги, таблицаbook_genre содержит информацию о жанрах книги.

ТабицаReader содержит идентификационную информацию читателя.

ТаблицаAdmin содержит идетификационную информацию администратора.

ТаблицаProfile включает информацию о дополнительных сведениях пользователя.

Физическая реализация базы данных реализована на основе использования СУБДMySQL.

2.3 Описание реализации программы

Опишем результат реализации программы. При запуске на экране появляется окно входа, показанное на рисунке 19.

Рисунок 19 Форма входа

Осуществим вход под аккаунтом администратора. На экране появится его меню (см. рис. 20).

Рисунок  Интерфейс администратора

Формы редактирования для таблиц «Книги», «Разделы» и «Читатели» приведены соответственно на рисунках 21, 22, 23.

Рисунок  Редактирование таблицы книги

Рисунок  Редактирование таблицы разделы книг

Рисунок  Редактирование таблицы читатели

При входе под аккаунтом пользователя (читателя) предлагается выбрать раздел книг (рис. 24).

Рисунок  Выбор раздела

После выбора раздела предлагается выбрать книгу (рис. 25).

Рисунок  Выбор книги

Заключение

В результате выполнения курсовой работы была разработана автоматизированная информационная система «Интернет-библиотека».

В процессе создания работы были полностью решены следующие задачи:

В результате работы представлен проект системы, а также работающий прототип.

Список использованных источников
  1. Калянов Г.Н.CASE-технологии. Консалтинг в автоматизации бизнес-процессов. – М.: Горячая линия - Телеком, 2015. – 320 с.
  2. Дж. Ульман Основы систем баз данных / Пер. с англ. М.Р. Когаловского и В.В. Когутовского – М.: Финансы и статистика, 1983. – 334 с., ил.
  3. Вендров А.М.CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.
  4. Флэнаган Д.JavaScript. Подробное руководство, 6-е издание. : Пер. с англ. – СПб.: Символ-Плюс, 2012. – 1080 с., ил.
  5. AJAX и PHP. Разработка динамических веб-приложений / К. Дари, Б. Бринзаре, Ф. Черчез-Тоза, М. Бусика — М.: Символ-Плюс, 2009.– 336 с.
  6. И. Шапошников PHP 5.1— М.: Питер, 2007. – 192 с.
  7. Закас Н. JavaScript. Оптимизация производительности. – Пер. с англ. – СПб.: Символ-Плюс, 2012. – 256 с., ил.
  8. Д. Котеров, А. Костарев PHP 5:— М.: БХВ-Петербург, 2008. – 1104 с.
  9. Конноли Т., Бегг К., Страчан А. Базы данных. Проектирование, реализация и сопровождение. – М.– С./П.– К., 2000.




Похожие работы, которые могут быть Вам интерестны.

1. ПРОГРАММНЫЙ КОМПЛЕКС VIRTUA В КАЧЕСТВЕ АВТОМАТИЗИРОВАННОЙ БИБЛИОТЕЧНО-ИНФОРМАЦИОННОЙ СИСТЕМЫ УНИВЕРСИТЕТСКОЙ БИБЛИОТЕКИ

2. Особенности реализации информационных правоотношений в Интернет. Вопросы правового обеспечения информационной безопасности в среде Интернет

3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ «АВТОСЕРВИС»

4. Разработка информационной системы для проведения аукционов

5. Разработка информационной системы учета посещаемости пациентов

6. Разработка информационной системы отдела кадров салона красоты

7. Разработка информационной системы для компании, продающих компьютеры и комплектующие»

8. Разработка базы данных и автоматизированной информационной системы (АИС) для театра

9. Разработка информационной системы АЗС с использованием клиент-серверной технологии

10. Разработка информационной системы туристического агентства: интерактивная модель и проектирование