К первой группе относятся следующие атрибуты качества:
) Доступность - атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
) Надежность - требование, описывающее поведение приложения или системы в нештатных ситуациях.
) Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
) Требования к удобству использования системы/приложения с точки зрения пользователя и требования к удобству и простоте поддержки
) Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
) Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи.
) Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи
Ко второй группе относятся следующие атрибуты качества:
) Требования к повторному использованию реализации или компонентов приложения или системы.
) Требования к расширяемости приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
) Требования к переносимости приложения или системы на другие платформы.
) Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия.
) Требования к поддержке системы или приложения. Среди этих параметров могут быть названы такие как, например, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
) Требования к модульности приложения или системы. Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
) Требования к возможности тестирования приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария.
) Требования к возможности и простоте локализации приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы.[10]
К проектируемой системе были выдвинуты следующие требования:
Функциональные:
) Безопасность и надежность хранения данных.
) Наличие функции резервного копирования базы данных.
) Информация о клиентах должна включать в себя ФИО, адрес проживания и телефон.
) Справочник Интернет-магазинов должен содержать название магазина, адрес и контактный телефон.
) Формирование необходимых отчетов.
) Информация о заказах должна включать в себя дату поступления заказа и срок его исполнения.
) В основе информационной системы должна быть локальная база данных.
) Возможность вывода отчетов на печать и их отправка по электронной почте.
Нефункциональные:
) Функциональность и полнота инструментария для работы с данными.
) Удобный и простой интерфейс.
) Наличие дополнительных инструментов, таких как дата и время, строка состояния, календари.
) Высокая скорость обработки запросов и формирования отчетов.
) Аутентификация при входе в программу.
) Наличие поиска по любому ключевому слову.
) Внесение в базу кода отслеживания почтового и курьерского отправления.
) Возможность комментировать записи базы для
удобства работы с записями.
.2 Модель вариантов использования
Основное действие пользователя при работе с проектируемой системой - редактирование данных. Пользователь будет вносить, изменять и удалять данные о клиентах, заказах, товарах. Диаграмма вариантов использования показывает, как будет проходить работа с программой. Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. [5]
Диаграммы вариантов использования применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к системе при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием.
Бизнес-анализ ставит целью понять структуру и динамику работы организации для которой разрабатывается программный продукт, определить проблемы, возникающие в работе организации, и возможности их решения, направленного на повышение эффективности работы.
Организация описывается как с внешней точки зрения - какие результаты предоставляются ее клиентам, так и с внутренней - роли, и их связи с деятельностью организации. Эта информация служит разработчику в качестве связующей при определении требований к реализуемой системе.
На диаграммах вариантов использования изображаются актеры и варианты использования, между которыми существуют отношения.
Актером называют внешнюю по отношению к разрабатываемой системе сущность, которая может взаимодействовать с ней. Актерами могут быть как люди, так и внешние системы или устройства. Актер это не всегда конкретный человек или устройство, а роль, должностная обязанность, в которой он выступает по отношению к программной системе.
Нахождение актеров - один из первых шагов в определении использования любой системы. Каждый источник внешних событий, с которыми должна взаимодействовать система, представляется как актер. Актер должен иметь имя, которое должно отражать его роль. На диаграммах вариантов использования актер изображается в виде стилизованной человеческой фигурки. При взаимодействии актера с системой последняя выполняет ряд работ, которые образуют вариант использования системы. Каждый актер может использовать систему разными способами, то есть инициировать выполнение разных вариантов использования. Таким образом, каждый вариант использования, по существу, есть некоторое функциональное требование к системе, которое, в свою очередь, может быть разбито на несколько более мелких. Вариант использования не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение в дальнейшем реализуется в виде классов и компонент.
Вариант использования описывает, что делает система, но не как она это делает. Каждый вариант использования обычно предполагает наличие нескольких вариантов поведения системы, один из которых является основным, остальные - альтернативными. Основной поток событий определяет последовательность действий системы, направленную на выполнение главной целевой функции данного варианта использования. Альтернативные потоки описывают поведение системы в исключительных ситуациях, например, при ошибках. Описание потоков событий может быть выполнено как в текстовой форме, так и с помощью диаграмм UML.
Каждый вариант использования должен иметь название, отвечающее его назначению. Название должно отражать, что достигается при взаимодействии с актерами. На диаграммах варианты использования изображаются в виде овала.
Ассоциация - единственно возможная связь между актером и вариантом использования. Она показывает, что актер и вариант использования общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения.
Отношение включения означает, что для полного осуществления основного варианта использования необходимо выполнение и включаемого варианта. В общем случае выделение включаемых вариантов использования будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Включение показывается пунктирной стрелкой, направленной от базового варианта к включаемому. Если вариант использования имеет фрагменты, которые по характеру являются необязательными или представляют собой исключения и при этом не способствуют лучшему пониманию основного назначения варианта использования можно создать расширяющий вариант использования. Начальный вариант становится базовым, который связывается с новым вариантом отношением расширения. Расширение показывается пунктирной стрелкой, направленной к расширяемому варианту использования. [11]
На основании выдвинутых требований была построена модель вариантов использования:
Рис. 2.1 Модель вариантов использования
.3 Модель предметной области
Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте информационной системы предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, в общем виде предметная область - это те объекты, действия или явления, с которыми работает ИС. [6]
Информационные системы - это программы для накопления и обработки информации. Банк данных - это система специальным образом организованных данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования. [7]
Требования, предъявляемые к базам данных:
) Адекватность отображения от предметной области.
) Возможность взаимодействия пользователей разных категорий.
) Дружелюбность интерфейса и малое время освоения системы.
) Обеспечение взаимной независимости программ и данных.
) Обеспечение надежности функционирования надлежащей секретности и защите данных от разрушения.
Для проектирования модели предметной области было принято решение использовать метод сущность-связь. Данный метод используется, когда количество атрибутов достаточно большое. Сущность - объект, некоторый класс, экземпляры которого имеют общие свойства и допускают однозначную идентификацию. Сущность соответствует реально существующему объекту, экземпляров сущности должно быть много. Почти всегда сущность можно записать в виде таблицы. Связь - это взаимоотношения между двумя сущностями. Атрибут - это одно из свойств сущности или один из столбцов таблицы сущности.
Атрибут или набор атрибутов, который используется для однозначной идентификации экземпляров, называется ключом сущности. Степень связи - это математическое отношение, определяющее сочетание экземпляров сущностей в этой связи. Бинарная связь - связь между двумя сущностями.
Для построения диаграммы сущность связь принято использовать ряд правил [8]:
) Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется всего одно отношение, объединяющее эти сущности. При этом ключом этого отношения может быть ключ любой сущности.
) Если степень бинарной связи 1:1 и класс принадлежности одной сущности является обязательным, а другой сущности - необязательным, то необходимо формировать два отношения: по одному для каждой сущности, причем ключ сущности с необязательным классом принадлежности добавляется в качестве атрибута в другое отношение.
) Если степень бинарной связи 1:1 и классы принадлежности обеих сущностей являются необязательными, то требуются три отношения: по одному для каждой сущности с соответствующими ключами и одно, выражающее связь и содержащее только ключи из каждой сущности.
) Если степень бинарной связи 1:m и класс принадлежности многосвязной сущности является обязательным, то достаточно формировать два отношения: по одному для каждой сущности с соответствующими ключами, при этом ключ односвязной сущности должен быть добавлен в качестве атрибута в отношение для многосвязной сущности.
) Если степень бинарной связи 1:m и класс принадлежности многосвязной сущности является необязательным, то необходимо формировать три отношения: по одному для каждой сущности с соответствующими ключами, и одно для связи аналогично третьему правилу.
) Если степень бинарной связи m:n, то необходимо формирование трех отношений: по одному для каждой сущности с соответствующими ключами и одного для связи аналогично третьему правилу.
) В случае трех и более сторонней связи необходимо формировать по одному отношению для каждой сущности и одно отношение, выражающее связь и содержащее только ключи каждой сущности. Ключ этого отношения выбирается также как в шестом правиле.
Основываясь на требованиях к системе и модели вариантов использования, была построена модель сущность-связь:
) Клиенты - данная сущность содержит контакты клиента для связи.
) Товары - представляет характеристики товара.
) Виды товаров - информация о видах товаров для доставки.
) Контракты на доставку - комплексная сущность, состоящая из ключей других таблиц.
) Статус доставки - справочник текущего состояния доставки товара.
Рис. 2.2. Диаграмма сущность-связь
Диаграмма предметной области также представлена диаграммой базы данных
проектируемой системы:
Рис. 2.3 Диаграмма базы данных
В данной диаграмме обозначены основные сущности предметной области, а так же их свойства. В частности представлены две сущности-справочника - списки видов товаров и статусы доставок.
Информация о клиентах включает в себя полное имя клиента, его телефон, домашний адрес и адрес электронной почты. Эти данные, в большинстве своём, обязательны для заполнения при оформлении заказов в интернет-магазинах.
Товары, включая посылки и клиента сделавшего заказ, также имеют информацию
о номере отправления для отслеживания через службу Почты России. Сюда же
включаются даты поступления и доставки заказанного товара, вес посылки,
количество заказанного товара и общая цена посылки с стоимостью доставки.
.4 Руководство пользователя
В начале работы с программой основные функции системы по соображениям безопасности недоступны. Для разблокировки интерфейса пользователю необходимо пройти авторизацию.
После прохождения авторизации пользователю становятся доступны все
функции системы, включая работу со справочниками, оформление заказов и
синхронизацию базы данных системы с сервисом Google Drive.