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

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

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

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

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

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

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

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

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

Если все-таки блокировка подтверждена, то с формы просмотра данных пользователя к классу Блокировка передается логин блокируемого и его e-mail. Пользователю с этим логином блокируется доступ к просмотру ресурсов с присвоением атрибуту Блокировка класса Пользователь значения 1(«заблокирован»), а на e-mail отправляется информация о том, что его владелец заблокирован. После выполнения указанных действий отображается Администраторская форма просмотра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регистрация

Регистрация инициируется пользователем с формы авторизации. Отображается форма регистрации, в которую пользователь должен ввести свои данные. После того как все поля заполнены, активируется кнопка регистрация. Пользователь запускает регистрацию. Управление переходит к управляющему классу Регистрация, созданному специально для данного прецедента. Этот класс проверяет корректность ввода данных и, если все нормально, проверяет номер телефона, введенный пользователем на повторение с помощью класса Пользователь. Если номер не повторяется, то класс Пользователь разрешает регистрацию новой учетной записи классу Регистрация. Тот в свою очередь генерирует и отправляет на указанный телефон код активации и отображает форму активации. В нее вводится код активации. После заполнения поля, на форме активируется кнопка «Активировать». Пользователь активирует учетную запись. С формы активации к классу Регистрация передается введенный код активации и ,если он совпадает с сгенерированным, отправляет введенные пользователем данные при регистрации классу Пользователь, для создания нового объекта класса. После того, как новая запись сохранена, отображается форма авторизации. На каждом из этих этапов (создание и активация учетной записи) регистрация может быть отменена. В любом случае после отмены отображается форма авторизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CRUD ресурсов

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

Добавление ресурса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удаление ресурса

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

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

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

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

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

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

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

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

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

Если же была выбрана отмена, то система возвращается на главную форму.

Диаграммы последовательности и кооперации для данного прецедента представлены на рисунках 88-91.

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

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

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

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

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

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

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

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

Рисунок 92. Диаграмма состояний для объекта Ресурс

Изначально ресурс находится в состоянии «Не просмотрен», т.е. этот ресурс еще не был просмотрен администратором. Затем, в процессе администрирования, когда ресурс просмотрен, он переходит в состояние «Просмотрен». Аналогично ведет себя и объект Пользователь (см. Рис. 93).

Рисунок 93. Диаграмма состояний для объекта Пользователь

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

Рисунок 94. Диаграмма состояний для объекта Пользователь

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

Для проектируемой системы наиболее подходящей является трехзвенная архитектура.

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

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

Трехуровневая архитектура была выбрана по следующим причинам:

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

- высокая безопасность

- высокая надёжность

- низкие требования к скорости канала (сети) между терминалами и сервером приложений

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

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

Заключение

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

2. Столбовский Д.Н. Проектирование ИС в экономике. - Владикавказ, 2014 г.

3. http://ooad.asf.ru (Объектно-ориентированный анализ и проектирование).

4. Кравец О.Я., Олейникова С.А., Практикум по проектированию ИС, Воронеж, 2010 г.

Размещено на Allbest.ru