Проектирование информационной системы, осуществляющей функции каталога ресурсов сети Интернет

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

Задание

Анализ требований

Выявление классов-сущностей

Выявление вариантов использований

Моделирование видов деятельности

Моделирование состояний

Моделирование архитектуры (диаграммы развертывания)

Заключение

Список литературы



Введение

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

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

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

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

Данная дипломная работа посвящена проектированию информационной системы, осуществляющей функции каталога ресурсов сети Интернет.

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

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



Задание

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

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

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

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

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

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

Анализ требований

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

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

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

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

Процедура регистрации включает следующие этапы:

– внесение личной информации в соответствующие поля;

– активация аккаунта через номер мобильного телефона;

– занесение нового логина и пароля в базу.

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

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

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

Имея логин и пароль, пользователь может авторизоваться в системе, после чего получает доступ к ней. При утрате пароля возможно восстановление.

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

Пользователь так же может отсортировать результаты по релевантности и по дате обновления. В дополнение к основному поиску возможно уточнение запроса и поиск по выборке.

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

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

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

Требования к системе будут уточняться в процессе проектирования.

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



Выявление классов-сущностей

моделирование пользовательский диаграмма архитектура

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

При анализе требований к системе были выявлены следующие классы:

– Пользователь

– Ресурс (класс, хранящий информацию о ресурсах)

– Раздел (класс, хранящий информацию о разделах)

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

Итак, рассмотрим атрибуты выявленных классов.

«Пользователь». Этот класс необходим для хранения информации о пользователях системы, в число которых входят и администраторы. Атрибутами этого класса являются:

– ФИО

– Пол

– Дата рождения

– Логин

– Пароль

– Номер телефона

– e-mail

– Дата регистрации

– Тип пользователя (Администратор или рядовой пользователь)

– Блокировка (Заблокирован или не заблокирован)

– Просмотр (Просмотрен или не просмотрен)

Последние два атрибута необходимы для работы администратора. Атрибут «Блокировка» позволяет хранить информацию о заблокированных пользователях, а атрибут «Просмотр» - регистрировать факт просмотра записи администратором.

Хранить телефон и e-mail пользователя необходимо для возможности связаться с ним при необходимости (оповестить о блокировке аккаунта) и для восстановления пароля при его утрате. Так же телефон выступает в роли идентификатора пользователя в системе.

Следующий класс - «Ресурс». Он предназначен для хранения информации о ресурсах, имеющихся в системе. Он состоит из из слежующих атрибутов:

– Код ресурса (идентификатор ресурса в БД)

– Наименование

– Адрес

– Описание

– Рейтинг

– Тэги

– Комментарий

– Просмотр

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

Третьим классом системы является класс «Раздел», который состоит из атрибутов

– Наименование

– Ресурс

Атрибуту «Ресурс» присвоен тип list <Ресурс>, т.е. атрибут будет состоять из списка объектов класса «Ресурс».

В итоге мы получаем 3 основных класса-сущности, выявленных на начальном этапе анализа требований:



Рисунок 1. Первоначальный вид диаграммы классов

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

Классы «Раздел» и «Пользователь» являются невзаимосвязанными классами. Оба эти класса связаны с классом «Ресурс»

Рассмотрим связь между классом «Ресурс» и классом «Раздел». Между этими классами содержится ассоциативная связь, т.к. в классе «Раздел» содержится ссылка на объекты класса «Ресурс». Но так как объекты класса «Ресурс» не могут существовать в отсутствии связи с классом «Раздел», то между ними имеют место отношение композиции, т.е. агрегации по значению.

Определим связь между классами «Ресурс» и «Пользователь». Эта ассоциация имеет следующие кратности: один ресурс может быть добавлен единственным пользователем (1), в то время как один пользователь может добавить как множество, так и ни одного ресурса (0..n).

Диаграмма классов с выявленными связями представлена на рисунке 2.

Рисунок 2. Диаграмма классов-сущностей

Выявление вариантов использования

Построение модели вариантов использования - процесс определения границ системы и актеров, выявления вариантов использования и объектов системы, детализации вариантов использования.

Границу системы называют также контекстом системы, который определяется тем, кто/что использует систему (актёры) и какие преимущества система им предлагает (варианты использования). Актёры располагаются вне контекста, а варианты использования - внутри контекста системы.

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

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

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

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

Модель вариантов использования для системы, реализующей функции каталога ресурсов сети Интернет представлена на рисунке 3.

Рисунок 3. Диаграмма вариантов использования проектируемой системы

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

Таблица 1. Спецификации вариантов использования проектируемой системы

Спецификация варианта использования «Регистрация
1. Краткое описание	Прецедент необходим для создания аккаунта пользователя в системе.
2. Субъекты	Пользователь
3.Предусловия	Открытие формы регистрации
4.1. Основной поток событий	Для начала выполнения прецедента субъект открывает форму регистрации. В эту форму он должен внести свои личные данные (Фамилия, Имя, Отчество, дата рождения, пол, телефон, e-mail, ), а так же свои логин и пароль. При этом пароль должен состоять не менее чем из семи символов английской раскладки разного регистра и арабских цифр. Ввод пароля нужно повторить дважды. При этом дата регистрации и код пользователя в базе пользователей заполняются автоматически. Кнопка «Регистрация» становится активной только после того, как все данные заполнены. После заполнения всех обязательных полей пользователь выбирает функцию регистрации аккаунта. После этого система переходит на форму активации учетной записи. Чтобы активировать аккаунт, пользователь должен внести в соответствующее поле код, который система отправляет на номер телефона указанный в форме регистрации. Далее пользователь выбирает функцию «Активировать учетную запись», которая активизируется после ввода кода активации. Далее система привязывает учетную запись к указанному номеру телефона, если к нему ранее не был привязан другой аккаунт, и сохраняет пользовательские данные и сведения об учетной записи в соответствующую базу. Так же регистрация может быть отменена на любом из этих шагов
4.2. Альтернативный поток событий	1) Пользователь ввел в какое-либо поле данные некорректного типа (недопустимые символы в пароле). В этом случае система после получения команды на регистрацию информирует субъект о возникшей ошибке и предлагает ее исправить. 2)Пользователь пытается активировать учетную запись через номер телефона, к которому уже привязан аккаунт. В случае такой ошибки система информирует пользователя о том, что данный номер телефона занят и предлагает ввести другой номер. 3)Несовпадение пароля при первичном и вторичном вводе. При возникновении такой ошибки, система осведомляет пользователя о ней и предлагает повторно ввести данные. 5) Ошибочный код активации. В этом случае система информирует об ошибке и предлагает повторный ввод кода. 6) Ошибочный код активации введен более 3 раз. Система блокирует активацию и предлагает пользователю попробовать позже.
5.Постусловия	В системе появляется информация о пользователе, его логине и пароле и номере телефона, к которому привязана учетная запись. Пользователь получает возможность авторизоваться.
Спецификация варианта использования «Авторизация»
1. Краткое описание	Прецедент необходим для авторизации (входа) субъекта в системе.
2. Субъекты	Пользователь, Администратор
3.Предусловия	Зарегистрированный субъект по каким-либо причинам хочет войти в систему для CRUD - а или просмотра ресурсов каталога и открывает форму авторизации.
4.1. Основной поток событий	Для начала выполнения прецедента субъект открывает форму авторизации. Ему предлагается заполнить поля ЛОГИН и ПАРОЛЬ. Если пользователь забыл свой логин или пароль, есть возможность воспользоваться прецедентом «Восстановить пароль» (см. спецификация прецедента «Восстановить пароль») с помощью вызова соответствующей функции. Далее пользователь выбирает функцию ВХОД. Кнопка активизируется после заполнения всех полей. Система авторизует пользователя, открывает ему доступ к системе и открывает главную форму.
4.2. Альтернативный поток событий	1)Субъект ввел несоответствующий логин и пароль. В этом случае после выбора команды Вход, система информирует об ошибке и предлагает повторно внести данные, либо восстановить логин или пароль, если они утеряны.
5.Постусловия	Пользователь авторизуется в системе и приобретает права на просмотр и редактирование ресурсов.
Спецификация варианта использования «Выход из системы»
1. Краткое описание	Прецедент необходим для выхода из системы.
2. Субъекты	Пользователь, Администратор
3.Предусловия	Завершен сеанс работы с системой
4.1. Основной поток событий	Для начала выполнения прецедента субъект вызывает функцию выхода. Система в ответ на данное действие предлагает продолжить операцию выхода или отменить ее. Если операция выхода продолжена, то система переходит на форму авторизации и блокирует доступ пользователя к просмотру и редактированию ресурсов пока он снова не авторизуется. Если же операция отменена, то система переходит к текущей форме.
4.2. Альтернативный поток событий	Отсутствует.
5.Постусловия	Пользователь отменяет авторизацию и теряет доступ к ресурсам системы.
Спецификация варианта использования «Восстановить пароль»
1. Краткое описание	Прецедент необходим для восстановления логина или пароля субъекта.
2. Субъекты	Пользователь.
3.Предусловия	Утерян пароль субъекта.
4.1. Основной поток событий	Для начала выполнения прецедента субъект вызывает функцию восстановления пароля или логина. Система в ответ на данное действие открывает форму восстановления аккаунта. Пользователю предлагается ввести логин и новый пароль. После ввода всех данных пользователь выбирает функцию Далее. Открывается форма, на которой пользователю предлагается внести в соответствующее поле код, отправленный на номер телефона, к которому привязана учетная запись, или же отменить операцию восстановления учетной записи. Если пользователь отменяет восстановление, то открывается форма авторизации. Если же он решил восстановить пароль, то на соответствующий номер, который система частично выведет на форму, отправляется сгенерированный автоматически код, который пользователь вносит в нужное поле. Пользователь нажимает кнопку Далее. Если код введенный пользователем соответствует сгенерированному системой коду, система меняет пароль в базе и открывается форма авторизации.
4.2. Альтернативный поток событий	1) Субъект не заполнил какие-либо поля. В этом случае система после получения команды на вход информирует субъект о возникшей ошибке и предлагает повторно ввести данные. 2)Субъект ввел несоответствующий код. В этом случае система информирует об ошибке и предлагает повторно внести данные, либо повторить отправку кода. 3)Попытка восстановления пароля к несуществующему логину. В этом случае система информирует об ошибке и предлагает повторно внести данные. 4) Ошибочный код восстановления введен более 3 раз. Система блокирует активацию и предлагает пользователю попробовать позже.
5.Постусловия	Пользователь получает новый пароль и восстанавливает свою учетную запись.
Спецификация варианта использования «Просмотр информации о пользователях»
1. Краткое описание	Прецедент необходим для просмотра информации о пользователях
2. Субъекты	Пользователь, Администратор.
3.Предусловия	Администратору необходимо проверить данные пользователя на соответствие правилам работы в системе, а пользователь просматривает свои личные данные.
4.1. Основной поток событий	Прецедент начинается с вызова субъектом функции просмотра информации о пользователе. Система проверяет тип субъекта. Если это пользователь, то она открывает форму просмотра его личной информации (т.к. доступ к информации других пользователей ему недоступен), в которой предусмотрена функция редактирования личных данных. Если это администратор, то система открывает форму просмотра для администратора, которая в отличие от пользовательской содержит список всех пользователей. При этом этот список отсортирован по дате регистрации и по факту просмотра (т.е. Просматривал администратор учетные записи или нет). Администратор выбирает пользователя, информацию о котором хочет просмотреть. Система в ответ на данное действие открывает форму просмотра информации о пользователе. Если данные пользователя не соответствуют правилам системы, то администратор может заблокировать пользователя, вызвав соответствующую функцию. Если же все данные корректны, то администратор возвращается к администраторской форме просмотра. При этом система автоматически присваивает этой записи статус просмотренной.
4.2. Альтернативный поток событий	1) При редактировании личных данных, пользователь не заполнил некоторые поля и попытался сохранить запись.
5.Постусловия	Пользователь просматривает и редактирует свою личную информацию. Администратор получает возможность просматривать информацию обо всех пользователях и блокировать пользователей с некорректной информацией в учетной записи. Записи пользователей делятся на просмотренные и не просмотренные.
Спецификация варианта использования «Просмотр ресурсов»
1. Краткое описание	Прецедент необходим для просмотра ресурсов, выложенных пользователями.
2. Субъекты	Пользователь, Администратор.
3.Предусловия	Субъект нашел ресурс, который ему необходимо просмотреть и открыл форму просмотра ресурсов.
4.1. Основной поток событий	Прецедент начинается с вызова субъектом функции просмотра ресурсов пользователей. Система проверяет тип субъекта. Если это пользователь, то она открывает пользовательскую форму просмотра ресурсов и автоматически вызывает функцию «Увеличение рейтинга». В этой форме пользователь может просмотреть содержание интернет ресурса. Если это администратор, то система открывает форму просмотра для администратора, которая отличается от пользовательской наличием кнопки «Удалить» для ресурсов, содержание которых противоречит правилам системы. Администратор выбирает ресурс, который хочет просмотреть. Система в ответ на данное действие открывает форму просмотра ресурса. Если ресурс пользователя не соответствует правилам системы, то администратор может удалить его, вызвав соответствующую функцию. Если же все данные корректны, то администратор возвращается к администраторской форме просмотра ресурсов. При этом система автоматически присваивает этому ресурсу статус просмотренного и увеличивает рейтинг.
4.2. Альтернативный поток событий	Отсутствует
5.Постусловия	Пользователь просматривает ресурсы, выложенные им в каталоге. Администратор получает возможность просматривать все ресурсы. Записи пользователей делятся на просмотренные и не просмотренные.
Спецификация варианта использования «Поиск ресурсов»
1. Краткое описание	Прецедент необходим для поиска ресурсов, выложенных пользователями.
2. Субъекты	Пользователь, Администратор.
3.Предусловия	Субъекту необходимо найти во всей совокупности ресурсов один конкретный, соответствующий определенным критериям.
4.1. Основной поток событий	Прецедент начинается с вызова субъектом функции поиска ресурсов пользователей. Открывается форма поиска ресурсов. В ней субъекту предлагается выбрать поле, по которому будет производиться поиск и ввести критерий поиска. При нажатии соответствующей кнопки, пользователь запускает поиск. Система после этого действия считывает из полей критерии поиска и производит поиск по соответствующим полям. В итоге на окно поиска выводится список ресурсов, соответствующих критериям. Если пользователь не доволен результатами поиска, он может уточнить запрос. Открывается форма уточнения запроса. Система осуществляет поиск уже по выборке, а не по всей базе.
4.2. Альтернативный поток событий	1) Пользователь ввел критерии поиска, которым нет соответствий в базе. В таком случае система информирует о данной ситуации и предлагает изменить запрос.
5.Постусловия	Субъект получает список ресурсов соответствующих введенным критериям.
Спецификация варианта использования «Сортировка ресурсов»
1. Краткое описание	Прецедент необходим для сортировки ресурсов, выложенных пользователями.
2. Субъекты	Пользователь, Администратор.
3.Предусловия	Администратору или пользователю необходимо выполнить сортировку ресурсов по определенному критерию.
4.1. Основной поток событий	Прецедент начинается с вызова субъектом функции сортировки ресурсов пользователей. Пользователь может отсортировать список по релевантности (соответствию ключевым словам запроса) или по дате обновления. А так же выбрать направление сортировки по возрастанию или по убыванию. После выбора всех параметров, пользователь запускает процесс сортировки. Система сортирует базу или выборку ресурсов (в зависимости от места вызова сортировки) по введенным параметрам и составляет отсортированный список ресурсов.
4.2. Альтернативный поток событий	Отсутствует.
5.Постусловия	Система составляет отсортированный по критериям список ресурсов.
Спецификация варианта использования «Блокировка пользователя»
1. Краткое описание	Прецедент необходим для блокировки пользователей, нарушающих правила системы.
2. Субъекты	Администратор.
3.Предусловия	Администратор выявил пользователя, нарушающего правила системы
4.1. Основной поток событий	Прецедент начинается с вызова администратором функции блокировки пользователей. Открывается форма выбора действия, предлагающая пользователю либо отменить блокировку, либо продолжить выбранное действие. Если выбирается отмена, то система переходит на предыдущую форму. Если же выбирается функция продолжения действия, то система блокирует функцию просмотра ресурсов до тех пор, пока не будет исправлен дефект и отправляет пользователю оповещение на указанный e-mail. Как только дефект будет исправлен, она восстанавливает возможность просмотра и использования системы.
4.2. Альтернативный поток событий	Отсутствует.
5. Постусловия	Появляется возможность блокировать нежелательных пользователей.
Спецификация варианта использования «CRUD ресурсов»
1. Краткое описание	Прецедент необходим для изменения, добавления и удаления ресурсов
2. Субъекты	Пользователь.
3.Предусловия	Возникла необходимость внесения изменений в список ресурсов.
4.1. Основной поток событий	Прецедент начинается с вызова одной из функции добавления, удаления или изменения ресурсов. Если выбирается функция добавления, то открывается форма добавления ресурса, в которую пользователь вносит информацию о ресурсе (раздел, наименование, адрес, тэги, комментарий и описание). После заполнения всех полей кнопка «Сохранить» становится активной. Далее выбирается функция сохранения, и система добавляет в базу новый ресурс. Если же выбирается функция удаления, пользователь выбирает из списка нужный ресурс и вызывает функцию удаления. Появляется форма выбора действия, где пользователь может отменить удаление или продолжить. Если выбрана отмена, то система переходит на текущую форму, если же выбрана функция продолжить, то система удаляет выбранный ресурс. Если выбрана функция редактирования, то открывается форма редактирования ресурса, в которую пользователь вносит необходимые изменения. После чего выбирает функцию сохранения. Появляется форма выбора действия, где пользователь может отменить сохранение или продолжить. Если выбрана отмена, то система переходит на текущую форму, если же выбрана функция продолжить, то система сохраняет изменения.
4.2. Альтернативный поток событий	Отсутствует
5.Постусловия	Система добавляет, удаляет и редактирует ресурсы.

Моделирование видов деятельности

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

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

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

Основными элементами диаграмм деятельности являются:

– овалы, изображающие действия объекта;

– линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»);

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

– стрелки -- отражают последовательность действий, могут иметь метки условий.

Рассмотрим диаграммы видов деятельности, построенные для проектируемой системы.

Рисунок 4. Диаграмма видов деятельности для прецедента «Регистрация»

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

Если пользователь по каким-либо причинам решил прервать регистрацию, то она может быть остановлена на любом из этих шагов.



Авторизация

Рисунок 5. Диаграмма видов деятельности для прецедента «Авторизация»

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

Выход из системы

Рисунок 6. Диаграмма видов деятельности для прецедента «Выход из системы»

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



Восстановление пароля

Рисунок 7. Диаграмма видов деятельности для прецедента «Восстановление пароля»

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

CRUD ресурсов

Рисунок 8. Диаграмма видов деятельности для прецедента «CRUD ресурсов»

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

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

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

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

Просмотр информации о пользователях

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

Рисунок 9. Диаграмма видов деятельности для прецедента «Просмотр информации о пользователях

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

Блокировка пользователя

Рисунок 10. Диаграмма видов деятельности для прецедента «Блокировка пользователя»

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

Сортировка результатов поиска

Рисунок 11. Диаграмма видов деятельности для прецедента «Сортировка ресурсов»

Сортировка ресурсов производится в рамках поиска. Поэтому отдельной формы для нее нет. Можно выбрать один из двух способов сортировки: по релевантности или по дате обновления. Далее осуществляется сортировка после запуска ее субъектом, а потом строится список ресурсов.

Поиск ресурсов

Рисунок 12. Диаграмма видов деятельности для прецедента «Поиск ресурсов»

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

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

Просмотр ресурсов

Рисунок 13. Диаграмма видов деятельности для прецедента «Просмотр ресурсов»

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

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

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



Моделирование взаимодействий

Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams).

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

Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

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

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

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

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



Авторизация

Рисунок 14. Диаграмма последовательности для основного потока прецедента «Авторизация»

Рисунок 15. Диаграмма кооперации для основного потока прецедента «Авторизация»

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

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

Если же пароль и логин не соответствуют, то отображается сообщение об ошибке на форме авторизации, что показано на Рис. 16 и 17.

Рисунок 16. Диаграмма последовательности для альтернативного потока прецедента «Авторизация»

Рисунок 17. Диаграмма кооперации для альтернативного потока прецедента «Авторизация»



Восстановление пароля

Рисунок 18. Диаграмма последовательности для основного потока прецедента «Восстановление пароля»

Рисунок 19. Диаграмма кооперации для основного потока прецедента «Восстановление пароля»

Для этого прецедента тоже были добавлены 2 класса. Управляющий класс Восстановление и пограничный класс Форма восстановления.

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

Далее, если все данные введены правильно, класс Восстановление отправляет классу Пользователь сообщение, чтобы он проверил наличие введенного логина. В противном случае, отображается сообщение об ошибке, как показано на Рис. 20 Класс Пользователь проверяет наличие принятого логина в базе и, если он найден, отправляет классу Восстановление номер телефона, к которому он привязан. Если же нет, то отображается сообщение об ошибке (см. Рис. 22 и 23).

Рисунок 20. Диаграмма последовательности для первого альтернативного потока прецедента «Восстановление пароля»

Рисунок 21. Диаграмма кооперации для первого альтернативного потока прецедента «Восстановление пароля»

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

Рисунок 22. Диаграмма последовательности для второго альтернативного потока прецедента «Восстановление пароля»

Рисунок 23. Диаграмма кооперации для второго альтернативного потока прецедента «Восстановление пароля»

Рисунок 24. Диаграмма последовательности для третьего альтернативного потока прецедента «Восстановление пароля»

Рисунок 25. Диаграмма кооперации для третьего альтернативного потока прецедента «Восстановление пароля»

Рисунок 26. Диаграмма последовательности для четвертого альтернативного потока прецедента «Восстановление пароля»

Рисунок 27. Диаграмма кооперации для четвертого альтернативного потока прецедента «Восстановление пароля»

Так же пользователь может на любом из шагов отменить восстановление пароля (см. Рис. 28-31).

Рисунок 28. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Рисунок 29. Диаграмма кооперации для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Рисунок 30. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Рисунок 31. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Поиск ресурсов

Для данного прецедента так же были добавлены один пограничный и один управляющий класс, Форма поиска и Поиск соответственно. Пользователь инициирует поиск, открывая соответствующее окно. Туда он вводит запрос на поиск и запускает его. Управление переходит к классу Поиск, который получает критерий для поиска. Затем класс Поиск отправляет классу Ресурс сообщение с критерием поиска. Ресурс выполняет поиск и передает его результаты обратно классу Поиск, который в свою очередь строит список результатов в Форме поиска.

Возможно так же, что будет введен критерий, которому нет соответствий в базе. Тогда на Форме поиска будет отображено сообщение о том, что поиск не дал результатов (см. Рис 34 и 35).

Рисунок 32. Диаграмма последовательности для основного потока прецедента «Поиск ресурсов»

Рисунок 33. Диаграмма кооперации для основного потока прецедента «Поиск ресурсов»

Рисунок 34. Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

Рисунок 35. Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

Так же у пользователя есть возможность проведения уточнения поиска, если результаты неудовлетворительны. Тогда после вышеуказанных действий, пользователь инициирует уточнение поиска. Вводит дополнительный критерий в поле на Окне поиска. Окно поиска передает критерий вместе с управлением классу Поиск, который производит дополнительный поиск в результатах, полученных ранее от класса Ресурс, а потом формирует список результатов на Форме поиска.

Рисунок 36. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии уточнения запроса

Рисунок 37. Диаграмма кооперации для прецедента «Поиск ресурсов» при условии уточнения запроса

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

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

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

Диаграммы взаимодействий для сортировки по релевантности и по дате обновления представлены на Рис. 38-39 и 40-41 соответственно.

Рисунок 38. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Рисунок 39 . Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Рисунок 40. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Рисунок 41. Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Просмотр информации о пользователях

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