2.4 Проектирование системы

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

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

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

• достичь соглашения с заказчиком и пользователями о том, что система должна делать;

• улучшить понимание разработчиком требований к системе;

• определить границы системы.

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

Разработка диаграммы вариантов использования (use case diagram) преследует цели:

• определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

• сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру, т.е. каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

На диаграмме отражены следующие актеры:

• Администратор – регистрирует, продлевает проживание, переселяет, выселяет клиентов, производит расчет с клиентами;

• Слушатель – производит прием заявок на питание, составляет меню, ведет учет продуктов на складе;

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

Рисунок 2.8 - Модель прецедентов.

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

Администратор заносит в БД всю необходимую информацию, производит производит необходимые настройки, и изменяет уровень доступа.

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

Эксперт идентичен по описанию актеру «Слушатель» но имеет больше прав доступа к данным.

Прецедент «Авторизация» активизируется всеми субъектами ИС. Прежде чем пользователю начать работу с системой, система запрашивает его пароль и логин. Если пользователь не зарегистрирован или в пароле и/или логине допустил ошибку, то он не получает доступа к работе в ИС. После успешной проверки логина и пароля пользователя открываются следующие возможности работы с системой:

- возможность создания теста (только для эксперта);

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

- возможность редактирования профиля;

- возможность редактировать БД (только для администратора);

- возможность Обучения (только для слушателя);

- возможность переписки через личные сообщения;

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

Прецедент «Редактирование профиля» инициируется актером «Эксперт», включает методы работы с личной информацией эксперта системы, такие как:

- аватар;

- пароль;

- ФИО;

- электронная почта;

- населенный пункт;

- район;

- населенный пункт;

- место работы;

- должность;

- сфера;

- статус пользователя;

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

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

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

Прецедент «Создание теста» позволяет пользователю со статусом «эксперт» создавать и редактировать тесты к курсу, тест создается в 2-х форматах:

1.вопрос и варианты ответов;

2.вопрос-ответ;

Прецедент «Тестирование» позволяет пользователю со статусом «слушатель» проходить тестирование.

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

Прецедент «Настройка оповещений» инициируется актером «Администратор», прецедент связанный с администратором, отвечает за параметры изменения оповещений портала, т.е RSS и рассылка через лс.

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

- личные сообщения;

- форум;

- регистрация;

- новости.

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