Описание предметной области Интернет-магазина (стр. 2 )

Рисунок 7 – Декомпозиция процесса «Добавление товаров в корзину»

Процесс «Добавление товаров в корзину» декомпозируется на 2 подпроцесса:

1) проверка присутствия товара на складе;

2) отправка данных о товаре в корзину. Этот процесс элементарен.

Рисунок 8 – Декомпозиция процесса «Проверка присутствия товара на складе»

Процесс «Проверка присутствия товара на складе» декомпозируется на 2 подпроцесса:

1) запрос информации о товаре на складе;

2) анализ результатов запроса товара.

Рисунок 9 – Декомпозиция процесса «Подтверждение заказа»

Процесс «Подтверждение заказа» декомпозируется на 3 подпроцесса:

1) подсчет стоимости заказа;

2) подтверждение заказа пользователем;

3) подтверждение заказа администратором.

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

1.4 Обоснование выбора принятых решений

Для проектирования функциональной модели To Be наиболее подходят две среды функционального моделирования – это Ramus и AllFusion Process Modeler 7 (BPwin). Эти среды является одними из самых известных и легко осваиваемых сред данного направления. Ramus и BPwin очень похожи, и их можно рассматривать как альтернативы друг друга. BPwin является более универсальной и простой средой в отличии от Ramus. Ramus в свою очередь имеет смысл использовать в достаточно больших и сложных организациях, чтобы он мог проявить свои преимущества в полной мере. Для небольших систем он может показаться громоздким в отличии от BPwin. Для функционального проектирования выбрана среда AllFusion Process Modeler 7 (BPwin). [3]

Для представления модели системы с разных точек зрения используются восемь видов канонических диаграмм (UML-диаграммы). Существует множество программ, которые позволяют строить эти диаграммы, но каждая из них позволяет построить только одну диаграмму. Среда IBM Software Rational Rose позволяет строить все виды диаграмм, а также удобна и проста в использовании. Также среда позволяет получать из одной диаграммы другую изоморфную ей автоматически (диаграммы последовательности и сотрудничества). Эта среда лучше всего подходит для составления UML-диаграмм разрабатываемой системы. [3]

Для моделирования данных подходят среды моделирования IBM Rational Data Architect и AllFusion ERwin Data Modeler. Обе среды позволяют составить логическую модель данных, а также визуализировать структуру данных путем моделирования. Первая в основном предназначена для работы с базами данных Oracle и IBM. Вторая позволяет сгенерировать SQL-скрипты по модели, что поможет в физической реализации базы данных. AllFusion ERwin Data Modeler является наиболее простой в управлении. Таким образом наиболее удобной средой для построения моделей данных разрабатываемой системы является AllFusion ERwin Data Modeler.

Для разработки программы в наибольшей степени подходят два языка программирования: С++ и Java. В обоих языках предусмотрена работа с SQL базами данных. Создание ИСИМ на любом из языков имеет приблизительно одинаковую сложность. В Java взаимодействие с базой данных предусмотрено посредством стандарта JDBC (Java Database Connectivity). Этот стандарт во многом упрощает работу с SQL базами данных. Для разработки ИСИМ выбран язык Java.

Наиболее популярными средами программирования на языке Java является Eclipse SDK и NetBeans IDE. NetBeans IDE основана на Eclipse, но она имеет расширенный и измененный функционал. Также NetBeans IDE позволяет графически разрабатывать интерфейс программы и поддерживает разработку веб-приложений. Для разработки ИСИМ выбрана среда NetBeans IDE.

Для создания и сопровождения баз данных системы подходят две СУБД: MySQL и Microsoft SQL Server. Обе системы работают с базами данных на основе языка SQL. Обе системы приблизительно в равной степени поддерживают защиту информации. Microsoft SQL Server более крупная система с большим числом возможностей по работе с базами данных. MySQL более простая и имеет меньший функционал. Так как информационная система интернет-магазина будет выполнять большую часть работы с базой данных, то большой функционал не требуется. В этом плане СУБД MySQL больше подходит для разрабатываемой системы. [4]

1.5 Техническое задание

1.5.1 Введение

Полное наименование программы: Информационная система интернет-магазина.

Краткое наименование программы: ИСИМ, система.

Работа выполняется на основании ГОСТ 19.102-77, ГОСТ 19.104-78 по требованию задания на курсовое проектирование.

Программа предназначена для автоматизированного учета информации о пользователях, товарах и заказах.

1.5.2 Требования к программе

1.5.2.1 Требования к функциональным характеристикам

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

1) авторизация при запуске программы;

2) просмотр информации о пользователях, товарах и заказах, находящихся в базе данных;

3) добавление новых пользователей и товаров в базу данных;

4) изменение и удаление информации о пользователях и товарах;

5) изменение информации о заказах.

1.5.2.2 Требования к надежности

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

1) организацией бесперебойного питания технических средств;

2) использованием лицензионного программного обеспечения;

3) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 01.01.01 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

4) регулярным выполнением требований ГОСТ «Защита информации. Испытания программных средств на наличие компьютерных вирусов».

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

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

1.5.3 Условия эксплуатации

1.5.3.1. Климатические условия эксплуатации

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

1.5.3.2. Требования к квалификации и численности персонала

Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единицы — системный администратор и конечный пользователь программы — администратор интернет-магазина. Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:

1) задача поддержания работоспособности технических средств;

2) задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы;

3) задача установки (инсталляции) программы;

4) задача создания резервных копий базы данных.

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

В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:

1) процессор AMD / Intel 1Hz, не менее;

2) оперативную память объемом, 512Мб, не менее;

3) HDD, 30 Гигабайт, не менее;

4) операционную систему Windows XP/Vista/7/8.

1.5.3.4. Требования к информационной и программной совместимости

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

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP/Vista/7/8.

Дополнительные требования к информационным структурам и методам решения не предъявляются.

Дополнительные требования к кодам и языкам программирования не предъявляются.

Требования к защите информации и программ не предъявляются.

1.5.3.5. Специальные требования

Программа должна обеспечивать одновременную работу не менее 10 пользователей с нескольких терминалов посредством интерфейса программы. Это требование должна обеспечивать СУБД базы данных.

1.5.4 Требования к программной документации

Состав программной документации должен включать в себя:

1) техническое задание;

2) спецификация требований;

3) программу и методики испытаний.

1.5.5 Технико-экономические показатели

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

1.5.6 Стадии и этапы разработки

1.5.6.1. Стадии разработки

Разработка должна быть проведена в три стадии:

1) разработка технического задания;

2) разработка рабочего проекта;

3) внедрение.

1.5.6.2. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка программы;

2) разработка программной документации;

3) испытания программы.

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

1.5.6.3. Содержание работ по этапам

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

1) подготовка задачи;

2) сбор исходных материалов;

3) выбор и обоснование критериев эффективности и качества разработки программы;

4) обоснование необходимости проведения научно-исследовательских работ.

На этапе научно-исследовательской работы должны быть выполнены следующие работы:

1) определение структур входных и выходных данных;

2) предварительный выбор методов решения задач;

3) обоснование целесообразности ранее разработанных программ;

4) определение требований к техническим средствам;

5) обоснование принципиальной возможности решения поставленной задачи.

На этапе разработки и утверждения технического здания должны быть выполнены следующие работы:

1) определение требований к программе;

2) разработка технико-экономического обоснования разработки программы;

3) определение стадий, этапов и сроков разработки программы и документации на нее;

4) выбор языков программирования;

5) определение необходимости проведения научно-исследовательских работ на последующих стадиях;

6) согласование и утверждение технического задания.

На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

1) разработка, согласование и утверждение и методики испытаний;

2) проведение приемо-сдаточных испытаний;

3) корректировка программы и программной документации по результатам испытаний.

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

1.5.7 Порядок контроля и приемки

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

2 ПРОЕКТИРОВАНИЕ

2.1 Проектирование логической модели данных

Исходя из предметной области интернет-магазина, можно выделить 3 основные сущности:

Пользователь [User] – представляет информацию о каждом пользователе.

Товар [Goods] – представляет информацию о товарах, имеющихся в наличии.

Заказ [Order] – представляет информацию о всех заказах пользователей.

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

Идентификационный номер пользователя [User ID] (ключевой атрибут).

Логин [Login] – Логин пользователя для входа в систему.

Пароль[Password].

Право администратора [Root] – обладает ли пользователь правами администратора.

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

Идентификационный номер товара [Goods ID] (ключевой атрибут).

Наименование [Name] – название товара.

Количество [Count] – количество товара на складе.

Цена [Price] – текущая цена одной единицы товара.

Для сущности Заказ определены следующие атрибуты:

Идентификационный номер заказа [Order ID] (ключевой атрибут).

Дата оформления заказа [Order Date] – дата подтверждения заказа пользователем.

Содержимое заказа [Contents].

Индикатор выполнения заказа [Exstat].

Заказчик [Login] – Логин пользователя, сделавшего заказ.

Теперь определим связи между сущностями.

Пользователь может выбрать несколько товаров для заказа и обратно – один товар может быть выбран несколькими пользователями. Поэтому связь от пользователя к товару – М:М (многие ко многим). Связь именуем как «выбирает» [Choose].

Пользователь может оформить несколько заказов, но один заказ не может быть оформлен несколькими пользователями. Поэтому связь от пользователя к заказу – 1:М (один ко многим). Имя связи – «оформляет» [Draw Up].

Товар может быть включен в несколько заказов и обратно – в одном заказе может быть выбрано несколько товаров. Поэтому связь от товара к заказу – М:М. Имя связи – «включен».

Рисунок 10 – ER-диаграмма модели данных

ER-модель, составленная по ER-диаграмме, выглядит следующим образом:

Рисунок 11 – Логическая модель данных

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

2.2 Проектирование физической модели данных

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

Рисунок 12 – Физическая модель данных

Все атрибуты сущностей стали полями таблицы. Каждое из полей должно иметь определенный тип. Поля таблицы Пользователь имеют следующие типы:

1) login (ключевое поле) – TEXT;

2) password – TEXT;

3) root – Integer.

Поля таблицы Товар имеют следующие типы:

1) goods ID (ключевое поле) – INTEGER;

2) name – TEXT;

3) price – INTEGER;

4) count – INTEGER.