Логическая модель ИС

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

Составление логической модели включает в себя:

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

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

Разработка требований к ИС

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

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

Требования к интернет-магазину:

• · Интернет магазин должен работать в режиме on-line.
• · Вся информация на сайте должна быть актуальной на текущий момент времени.
• · Все изменения, сделанные пользователем (сформированные, измененные заказы и т. д.), должны немедленно отображаться в учетной системе и быть доступны менеджерам для дальнейшей обработки.
• · Ни один сформированный/измененный пользователем документ не должен остаться незамеченным менеджерами магазина.
• · После проведения документов менеджером, пользователь Интернет-магазина не может изменять и удалять документы.

Данная предметная область рассматривается как с точки зрения клиента, так и с точки зрения менеджера.

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

Менеджер принимает заказ и проверяет наличие этого заказа на складе в магазине, если товара нет, то менеджер заказывает товар у поставщика. Так же менеджер проверяет оплату заказа.

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

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

Для работы системы информационного ресурса магазина «DNS» на диаграмме вариантов использования были выделены следующие акторы:

Клиент — это обычные люди, которые просматривают информацию и получают сведения о магазине, осуществляют заказ товара, а также имеющие ограничение доступа к системе;

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

Диаграмма последовательностей данной предметной области изображена на рисунке 4. На данной диаграмме показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления.

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

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

Вход в систему.

• 1) Наименование: Вход в систему.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: Вход в систему служит для того, чтобы клиент мог в своем личном кабинете осуществлять заказ необходимого товара, оплачивать его, получать различные уведомления по его заказу.
• 4) Авторы прецедента: автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: вход в систему обязателен, если клиент намерен сделать заказ.
• 9) Предусловия: вход на сайт.
• 10) Постусловия: если клиент не может войти на сайт, то ему следует зарегистрироваться, если же вход выполнен, то клиент может просматривать каталог товаров, либо какие-то другие действия, которые ему доступны.
• 11) Приоритетный маршрут: зайдя на сайт, пользователь выполняет вход в систему, либо регистрируется, для дальнейших действий.
• 12) Альтернативный маршрут: пользователь может просматривать каталог товаров без входа в систему.
• 13) Исключительный маршрут: нет.

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

Регистрация.

• 1) Наименование: Регистрация.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: регистрация необходима для того, чтобы пользователь мог войти в систему под своим логином и паролем.
• 4) Авторы прецедента: автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: регистрация обязательна, если пользователь намерен выполнить вход в систему.
• 9) Предусловия: вход на сайт.
• 10) Постусловия: после успешной регистрации, пользователь вводит пароль и логин и происходит авторизация.
• 11) Приоритетный маршрут: зайдя на сайт, незарегистрированный пользователь выполняет регистрацию для дальнейших действий.
• 12) Альтернативный маршрут: пользователь может просматривать каталог товаров без регистрации.
• 13) Исключительный маршрут: нет.

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

Выбрать товар.

• 1) Наименование: Выбрать товар.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: клиент может выбрать товар, просмотрев каталог товаров.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: клиент может зайти на сайт, чтобы ознакомиться с каталогом товаров и выбрать необходимый для него товар.
• 9) Предусловия: вход в систему.
• 10) Постусловия: после выбора товара пользователь может оформить заказ.
• 11) Приоритетный маршрут: войдя в систему, пользователь осуществляет выбор необходимого товара в каталоге.
• 12) Альтернативный маршрут: нет.
• 14) Исключительный маршрут: нет.

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

Заказать товар.

• 1) Наименование: Заказать товар.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: выбрав необходимый товар из каталога товаров, клиент может сделать заказ, указав все необходимые параметры.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: если клиент выбрал товар и имеет желание приобрести его на сайте, то он может оформить заказ.
• 9) Предусловия: выбор товара.
• 10) Постусловия: после оформления заказа, клиент обязан его оплатить.
• 11) Приоритетный маршрут: выбрав товар, пользователь создает заказ.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: клиент может отказаться от заказа товара.

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

Рассмотреть способы оплаты.

• 1) Наименование: Рассмотреть способы оплаты.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: для того чтобы оплатить заказ необходимо рассмотреть способы оплаты заказа.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: заказав товар, клиент получает счет, который необходимо оплатить, для этого он рассматривает способы оплаты заказа.
• 9) Предусловия: заказ товара.
• 10) Постусловия: оплата заказа.
• 11) Приоритетный маршрут: для того, чтобы оплатить заказ необходимо рассмотреть его способы оплаты.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: нет.

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

Оплатить заказ.

• 1) Наименование: Оплатить заказ.
• 2) Акторы, взаимодействующие с прецедентом: Клиент.
• 3) Описание: для того чтобы заказать оборудование необходимо оплатить его.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: заказав товар, клиент получает счет, который необходимо оплатить.
• 9) Предусловия: заказ товара.
• 10) Постусловия: заказ оплачен.
• 11) Приоритетный маршрут: рассмотрев способы оплаты, клиент оплачивает заказ.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: если заказ не оплачен, он отменяется.

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

Принятие заказа.

• 1) Наименование: Принятие заказа.
• 2) Акторы, взаимодействующие с прецедентом: Менеджер.
• 3) Описание: необходимо проверить менеджеру правильно ли клиент оформил заказ.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: после того, как заказ будет оформлен клиентом, менеджер осуществляет его принятие.
• 9) Предусловия: заказ товара.
• 10) Постусловия: заказ принят.
• 11) Приоритетный маршрут: менеджер должен проверить заказ, и если все верно, то осуществить принятие заказа, если же что-то не так, то сообщить клиенту об ошибке.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: нет.

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

Проверка наличия товара на складе.

• 1) Наименование: Проверка наличия товара на складе.
• 2) Акторы, взаимодействующие с прецедентом: Менеджер.
• 3) Описание: служит для того, чтобы менеджер проверил имеется ли данный товар на складе.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: если товар имеется на складе, то необходимо сообщить клиенту об этом, ели же не имеется, то менеджер заказывает его у поставщика.
• 9) Предусловия: принятие заказа от клиента.
• 10) Постусловия: заказ товара у поставщика, проверка оплаты заказа.
• 11) Приоритетный маршрут: после того, как менеджер принял заказ, необходимо проверить наличие товара на складе.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: нет.

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

Проверка оплаты заказа.

• 1) Наименование: Проверка оплаты заказа.
• 2) Акторы, взаимодействующие с прецедентом: Менеджер.
• 3) Описание: менеджеру необходимо проверить оплату заказа.
• 4) Авторы прецедента: сотрудники, автор курсовой работы.
• 5) Географическое нахождение прецедента: сервер.
• 6) Статус: текущая фаза детализации.
• 7) Приоритет: высокий.
• 8) Предположение: после того, как клиенту будет отправлен счет, он обязан его оплатить, менеджер, в свою очередь, должен проследить, чтобы все заказы были оплачены.
• 9) Предусловия: принятие заказа от клиента.
• 10) Постусловия: заказ оплачен.
• 11) Приоритетный маршрут: после принятия заказа, менеджер выставляет счет клиенту и следит за его оплатой.
• 12) Альтернативный маршрут: нет.
• 13) Исключительный маршрут: если клиент не оплатил заказ, то заказ является недействительным.

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