Разработка информационной системы "Интернет-магазин компьютеров"

Размещено на http://www.allbest.ru/

1

Содержание

Введение

1. Разработка технического проекта

1.1 Постановка задачи

1.2 Требования к проекту

2. Методологии функционального моделирования

2.1 Моделирование функциональных требований к БД

2.2 Логическая схема

3. Функциональная схема

3.1 Диаграмма прецедентов

3.2 Описание прецедентов

4. Диаграмма деятельности

Заключение

Список используемой литературы



Введение

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

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

Практически в любой области деятельности люди используют тот или иной вид моделей (математических, физических или компьютерных), чтобы иметь более ясное представление о том, что они делают. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации [1].

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов (разработка требований, проектирование, реализация, тестирование, вход в действие).

Проектирование ИС охватывает три основные области:

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

· требуемой пропускной способности системы;

· требуемого времени реакции системы на запрос;

· безотказной работы системы;

· необходимого уровня безопасности;

· простоты эксплуатации и поддержки системы.

Сегодняшняя революция в информационных технологиях изменяет традиционные представления о ведении бизнеса. Электронная коммерция уравнивает шансы в привычной конкурентной борьбе, позволяя как крупным, так и мелким компаниям состязаться на равных в качестве, цене, ассортименте продукции. При затратах, равных стоимости рекламного объявления в местной газете, она дает торговым организациям доступ к мировому рынку, недоступному для малых компаний никакими другими средствами [2].

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

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

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



1. Разработка технического проекта

1.1 Постановка задачи

Магазин компьютеров предлагает возможность приобретения своих товаров через Интернет. Клиент может выбрать компьютер на web-странице магазина. Компьютеры подразделяются на серверы, настольные, портативные и карманные. Заказчик может выбрать стандартную конфигурацию из списка и детально ознакомиться с ней на отдельной web-странице. Если стандартная конфигурация ему не подходит, он может построить требуемую ему конфигурацию в диалоговом режиме. Компоненты конфигурации (такие, как оперативная память, процессор, жесткий диск и т. п.) представляются как список для выбора из доступных альтернатив. Для каждой новой конфигурации система может подсчитать цену. Чтобы оформить заказ, клиент должен заполнить электронную форму с адресами для доставки товара и отправки счета-фактуры, а также деталями, касающимися оплаты. Оплата компьютеров осуществляется наличными курьеру, осуществляющему доставку, или банковским переводом на счет интернет-магазина. После ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждением получения заказа вместе с относящимися к нему деталями (стоимость, номер счета, банковские реквизиты для безналичной оплаты и т. п.). Пока клиент ожидает прибытия компьютера, он может проверить состояние заказа (поставлен в очередь / собран / отправлен). Работник магазина проверяет, поступила ли оплата (в случае безналичного расчета) и делает соответствующую пометку при поступлении денег. Если деньги не поступают в течение 5 банковских дней, заказ аннулируется. После оплаты или в случае оплаты наличными работник печатает счет-фактуру и отправляет ее на склад вместе с требованием заказанной конфигурации. Заказ помечается как поставленный в очередь. Собранный компьютер вместе со счетом-фактурой и накладной передается со склада в отдел доставки, при этом заказ помечается как собранный. Компьютер поставляется клиенту (статус заказа - отправлен). Если заказ оплачивается наличными, курьер по возращении передает деньги в кассу, заказ помечается как оплаченный. По окончании работы с заказом, он помечается в системе как выполненный. Заказы хранятся в системе в течение 15 месяцев с момента создания для составления годовых и квартальных отчетов, после чего автоматически удаляются.

1.2 Требования к проекту

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

Система должна выполнять следующие функции:

Формирование заказа;

Подбор компьютеров в зависимости от требований клиента;

Подсчёт стоимости выбранного товара;

Доставка товара клиенту;

Предоставление отчёта о сформированном заказе;

Предоставление возможности просмотра состояния заказа.

Исходные данные:

· Предлагаемый товар;

· Адрес для доставки;

· Метод оплаты.

Результаты:

· Отчёт о сформированном заказе;

· Состояние заказа;

· Счёт-фактура;

· Требование заказанной конфигурации;

· Накладная;

· Доставленный заказ.

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

Для обеспечения надежности информационной системы «Интернет-магазин компьютеров» необходимо:

· Проверка на заполнение всех полей формы заказа;

· Проверка на корректность вводимых данных (адрес электронной почты, наличие цифр в Фамилии и имени и т.д.)

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

Система может работать как на IBM совместимых компьютерах, так и на ноутбуках, нетбуках, сотовых телефонах с выходом в интернет.

Минимальная конфигурация:

Наличие выхода в интернет.

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

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

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

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

В состав сопровождающей документации должны входить:

Пояснительная записка.

Руководство пользователя.



2. Методологии функционального моделирования

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

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

· методология функционального моделирования работ SADT (Structured Analysis and Design Technique);

· диаграммы потоков данных DFD (Data Flow Diagrams);

· методология объектного проектирования на языке UML (UML-диаграммы).

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом и является одной из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта, -IDEF0 (Icam DEFinition) является частью программы ICAM (Integrated Computer -Aided Manufacturing - интегрированная компьютеризация производства)[3].

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

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

Основными понятиями методологии функционального моделирования работ являются:

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

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

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

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

Механизм (Mechanism) - ресурсы, которые выполняют работу (персонал, станки, устройства - стрелка, входящая в нижнюю грань).

Вызов (Call) представляет собой взаимодействие одной модели работ с другой (стрелка, исходящая из нижней грани).

Различают в IDEF0 пять типов связей работ.

Связь по входу (input-output) имеет место, когда выход вышестоящей работы направляется на вход следующей работы.

Связь по управлению (output-control) обозначает ситуацию, когда выход вышестоящей работы направляется на управление следующей работы. Связь показывает доминирование вышестоящей работы.

Обратная связь по входу (output-input feedback) имеет место, когда выход нижестоящей работы направляется на вход вышестоящей. Используется для описания циклов.

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

Связь выход-механизм (output-mechanism) имеет место, когда выход одной работы направляется на механизм другой и показывает, что работа подготавливает ресурсы для проведения другой работы.

На рисунках 1, 2 представлены первый и второй уровни диаграммы работы ИС «Интернет-магазин компьютеров», описывающие принципы функционирования системы.

2.1 Моделирование функциональных требований к БД

Для построения модели проектируемой ИС воспользуемся моделью потоков данных. Диаграммы потоков данных (Data Flow Diagrams - DFD) используются для описания движения документов и обработки информации как дополнение к IDEF0. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой. DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. DFD - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные [4].

Диаграмма потоков данных содержит:

· процессы, которые преобразуют данные;

· потоки данных, переносящие данные;

· активные объекты, которые производят и потребляют данные;

· хранилища данных, которые пассивно хранят данные.

На рисунке 3 изображена диаграмма потоков данных ИС «Интернет-магазин компьютеров».

2.2 Логическая схема

Основой логической модели статического представления моделируемой системы является диаграмма классов.

Классы - это базовые элементы любой объектно - ориентированной системы. Они представляют собой описание совокупностей однородных объектов с присущими им свойствами - атрибутами, операциями, отношениями и семантикой.

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

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

Логические взаимосвязи представляют собой связи между сущностями. Они определяются глаголами, показывающими, как одна сущность относится к другой[5].

Некоторые примеры взаимосвязей:

* команда включает много игроков;

* самолет перевозит много пассажиров;

* продавец продает много продуктов.

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

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

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

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

· Никакой из атрибутов первичного ключа не должен иметь нулевое значение.

· Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.[6]

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

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

Таблица 1 - Атрибуты сущности «Клиент»

Атрибут	Описание
ID клиента	Уникальный номер для идентификации клиента
Ф.И.О.	Фамилия, имя и отчество клиента
Адрес	Адрес проживания, куда будет доставлен заказ
E-mail	Адреса электронной почты
ID заказа	Уникальный номер сделанного данным клиентом заказа

Так как клиент формирует заказ из предложенного товара, определим сущность «Товар» или «Прайс-лист» (таблица 2).

Таблица 2 - Атрибуты сущности «Товар»

Атрибут	Описание
ID товара	Уникальный номер для идентификации товара
Наименование	Полное название товара
Цена	Стоимость данного товара
Вид конфигурации	Стандартная или Комплектующие; если Стандартная: Серверы/Настольные/Портативные/Карманные
Описание	Подробное описание и характеристики

Определим сущность «Заказ» (таблица 3).

Таблица 3 - Атрибуты сущности «Заказ»

Атрибут	Описание
ID заказа	Уникальный номер для идентификации заказа
Сумма заказа	Подсчитанная стоимость заказа
Оплачен	Да или Нет
ID товара	Уникальные номера товаров, составляющих данный заказ
Состояние заказа	Поставлен в очередь/Собран/Отправлен
Номер счёта	Для оплаты данного заказа
Вид оплаты	Курьеру/ Переводом на счёт

Составляется ERD-диаграмма, определяя типы атрибутов и проставляя связи между сущностями (рисунок 4). Связь «Клиент» - «Заказ» - «один-к-одному», а «Заказ» - «Товар» - «один-ко-многим».

Рисунок 4 - ERD-диаграмма ИС «Интернет-магазин компьютеров»

Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов (таблица 4).

Таблица 4 - Типы атрибутов

Атрибут	Тип
ID клиента	Number
Ф.И.О.	String
Адрес	String
E-mail	String
ID заказа	Number
ID товара	Number
Наименование	String
Цена	Number
Вид конфигурации	String
Описание	String
Сумма заказа	Number
Оплачен	Number
Состояние заказа	String
Номер счёта	Number
Вид оплаты	String



Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Клиент» это будет ID клиента, для сущности «Товар» - ID товара, для сущности «Заказ» - ID заказа и номер счёта.



3. Функциональная схема

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

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

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

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

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

· Отношение ассоциации (association) - определяет наличие канала связи между экземплярами субъекта и прецедента (или между экземплярами двух субъектов). Обозначается сплошной линией, возможно наличие стрелки и указание мощности связи.

· Отношение расширения (extend) - определяет взаимосвязь экземпляров отдельного прецедента с более общим прецедентом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Обозначается пунктирной линией со стрелкой, направленной от того прецедента, который является расширением для исходного прецедента, и помечается ключевым словом "extend" ("расширяет").

· Отношение включения (include) - указывает, что некоторое заданное поведение для одного прецедента включает в качестве составного компонента поведение другого прецедента. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров прецедентов всегда упорядочена в отношении включения. Обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому, и помечается ключевым словом "include" ("включает").

· Отношение обобщения (generalization) - служит для указания того факта, что некоторый прецедент А может быть обобщен до прецедента В. В этом случае прецедент А будет являться специализацией прецедента В. При этом В называется предком или родителем по отношению к А, а прецедент А - потомком по отношению к прецеденту В.[5]

3.1 Диаграмма прецедентов

На рисунке 1 приведена диаграмма прецедентов для информационной системы «Интернет-магазин компьютеров». В данной системе можно выделить следующие субъекты и соответствующие им прецеденты:

· Web-страница - предоставляет пользователю список доступной конфигурации (прецедент «Выбор ПК»), подсчитывает стоимость выбранного ПК («Подсчёт стоимости ПК»), участвует в оформлении заказа («Оформление заказа»);

· Работник магазина - проверяет, оплачен ли заказ («Проверка оплаты»);

· Склад - «Сбор ПК»;

· Отдел доставки;

· Курьер - доставляет ПК («Доставка ПК»);

· Клиент - выбирает ПК, оформляет заказ и оплачивает его.

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

Дальнейшее развитие модели поведения системы предполагает описание прецедентов. Типичное описание содержит следующие разделы:

· Краткое описание;

· Участвующие субъекты;

· Предусловия, необходимые для инициирования прецедента;

· Основной поток событий;

· Альтернативный поток событий;

· Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.

3.2 Описание прецедентов

Таблица 5 - Описательная спецификация прецедента "Выбор ПК"

Раздел	Описание
1	2
Краткое описание	Клиент может выбрать компьютер на web-странице магазина. Компьютеры подразделяются на серверы, настольные, портативные и карманные. Заказчик может выбрать стандартную конфигурацию из списка и детально ознакомиться с ней на отдельной web-странице. Если стандартная конфигурация ему не подходит, он может построить требуемую ему конфигурацию в диалоговом режиме. Компоненты конфигурации (такие, как оперативная память, процессор, жесткий диск и т. п.) представляются как список для выбора из доступных альтернатив. Для каждой новой конфигурации система может подсчитать цену.
Субъекты	Клиент, Web-страница.
Предусловия	Имеется список товаров, клиент может просмотреть список и детально ознакомиться с его содержимым.
Основной поток	Клиент выбирает стандартную конфигурацию из списка и детально знакомиться с ней на отдельной web-странице. Затем ему сообщается сумма заказа.
Альтернативный поток	Если стандартная конфигурация не подходит клиенту, он строит требуемую ему конфигурацию в диалоговом режиме. Компоненты конфигурации представляются как список для выбора из доступных альтернатив. Для каждой новой конфигурации система подсчитывает цену.
Постусловия	Конфигурация выбрана, клиент может приступать к оформлению заказа.

Таблица 6 - Описательная спецификация прецедента "Оформление заказа"

Раздел	Описание
1	2
Краткое описание	Чтобы оформить заказ, клиент должен заполнить электронную форму с адресами для доставки товара и отправки счета-фактуры, а также деталями, касающимися оплаты. Оплата компьютеров осуществляется наличными курьеру, осуществляющему доставку, или банковским переводом на счет интернет-магазина. После ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждением получения заказа вместе с относящимися к нему деталями (стоимость, номер счета, банковские реквизиты для безналичной оплаты и т. п.).
Субъекты	Клиент, Web-страница.
Предусловия	Клиент выбрал требуемую конфигурацию, открыта электронная форма.
Основной поток	Клиент заполняет электронную форму с адресами для доставки товара и отправки счета-фактуры, а также деталями, касающимися оплаты. После ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждением получения заказа вместе с относящимися к нему деталями. В базу данных вносится информация о клиенте и сделанном им заказе.
Альтернативный поток	-
Постусловия	Электронная форма заполнена, система отправила клиенту по электронной почте сообщение с подтверждением получения заказа.

Таблица 7 - Описательная спецификация прецедента «Подсчёт стоимости ПК»

Раздел	Описание
1	2
Краткое описание	Для каждой выбранной конфигурации система может подсчитать цену.
Субъекты	Клиент, Web-страница.
Предусловия	Клиент выбрал требуемую ему конфигурацию из списка доступных альтернатив.
Основной поток	Система подсчитывает цену в диалоговом режиме.
Альтернативный поток	Если конфигурация стандартная - подсчёт цены не требуется, так как стоимость уже указана.
Постусловия	Стоимость комплекта подсчитана.

Таблица 8 - Описательная спецификация прецедента «Отправка электронного письма»

Раздел	Описание
1	2
Краткое описание	После ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждением получения заказа вместе с относящимися к нему деталями (стоимость, номер счета, банковские реквизиты для безналичной оплаты).
Субъекты	Клиент, Web-страница.
Предусловия	Заказ сформирован, указан адрес электронной почты клиента.
Основной поток	После оформления заказа на электронную почту отправляется письмо с подтверждением получения заказа вместе с относящимися к нему деталями.
Альтернативный поток	-
Постусловия	Электронное письмо успешно доставлено клиенту.



Таблица 9 - Описательная спецификация прецедента «Оплата заказа»

Раздел	Описание
1	2
Краткое описание	Оплата компьютеров осуществляется наличными курьеру, осуществляющему доставку, или банковским переводом на счет интернет-магазина.
Субъекты	Клиент, наличные.
Предусловия	Выбран способ оплаты при оформлении заказа.
Основной поток	Оплата осуществляется наличными курьеру, доставившему заказ.
Альтернативный поток	Оплата осуществляется банковским переводом на счет интернет-магазина.
Постусловия	Деньги получены либо переведены на счёт интернет-магазина.

Таблица 10 - Описательная спецификация прецедента «Проверка оплаты заказа»

Раздел	Описание
1	2
Краткое описание	Работник магазина проверяет, поступила ли оплата (в случае безналичного расчета) и делает соответствующую пометку при поступлении денег. Если деньги не поступают в течение 5 банковских дней, заказ аннулируется. После оплаты или в случае оплаты наличными работник печатает счет-фактуру и отправляет ее на склад вместе с требованием заказанной конфигурации. Заказ помечается как поставленный в очередь.
Субъекты	Клиент, работник магазина.
Предусловия	Заказ оформлен и подтверждён.
Основной поток	После оплаты или в случае оплаты наличными работник печатает счет-фактуру и отправляет ее на склад вместе с требованием заказанной конфигурации. Заказ помечается как поставленный в очередь.
Альтернативный поток	Если деньги не поступают в течение 5 банковских дней, заказ аннулируется.
Постусловия	Сделана запись в базе данных об оплате заказа.

Таблица 11 - Описательная спецификация прецедента «Сбор ПК»

Раздел	Описание
Краткое описание	После оплаты работник печатает счет-фактуру и отправляет ее на склад вместе с требованием заказанной конфигурации. На складе заказ собирается. Собранный компьютер вместе со счетом-фактурой и накладной передается со склада в отдел доставки, при этом заказ помечается как собранный.
Субъекты	Работник, счёт-фактура.
Предусловия	Поступила оплата.
Основной поток	Работник печатает счет-фактуру и отправляет ее на склад вместе с требованием заказанной конфигурации. На складе заказ собирается и передаётся в отдел доставки. Изменяется статус заказа.
Альтернативный поток	-
Постусловия	Заказ собран и доставлен в отдел доставки.

Таблица 12 - Описательная спецификация прецедента «Состояние заказа»

Раздел	Описание
1	2
Краткое описание	Пока клиент ожидает прибытия компьютера, он может проверить состояние заказа (поставлен в очередь / собран / отправлен).
Субъекты	Клиент, Web-страница.
Предусловия	Заказ оформлен.
Основной поток	После отправки счета-фактуры на склад вместе с требованием заказанной конфигурации, заказ помечается как поставленный в очередь. Собранный ПК передается со склада в отдел доставки, при этом заказ помечается как собранный. Компьютер поставляется клиенту (статус заказа - отправлен). По окончании работы с заказом, он помечается в системе как выполненный.
Альтернативный поток	Если заказ оплачивается наличными, курьер по возращении передает деньги в кассу, заказ помечается как оплаченный.
Постусловия	Возможен просмотр статуса заказа.

Таблица 13 - Описательная спецификация прецедента «Доставка ПК»

Раздел	Описание
1	2
Краткое описание	Компьютер поставляется клиенту (статус заказа - отправлен).
Субъекты	Клиент, курьер.
Предусловия	Заказ оформлен, оплачен, собран.
Основной поток	Курьер поставляет клиенту заказ.
Альтернативный поток	-
Постусловия	Заказ доставлен. Будет автоматически удалён через 15 месяцев.



4. Диаграмма деятельности

Диаграммы деятельности (Activity diagram), называемые также диаграммами активности или диаграммами видов деятельности, были введены в язык UML сравнительно недавно. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения. [12]

Диаграмма деятельности отличается от традиционной блок-схемы

· более высоким уровнем абстракции;

· возможностью представления с помощью диаграмм деятельности управления параллельными потоками наряду с последовательным управлением.

Основными направлениями использования диаграмм деятельности являются

· визуализация особенностей реализации операций классов;

· отображение внутрисистемной точки зрения на прецедент.

В последнем случае диаграммы деятельности применяют для описания шагов, которые должна предпринять система после того, как инициирован прецедент

Разработка диаграммы деятельности преследует цели:

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

· выделить последовательные и параллельные потоки управления;

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

Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия или состояния деятельности, а дугами - переходы от одного состояния действия/деятельности к другому. Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния (на практике иногда можно видеть несколько конечных состояний на одной диаграмме, но это одно и тоже состояние, изображенное несколько раз для лучшей читабельности диаграммы). Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное - в ее нижней части.[13]

Рассмотрим основные элементы диаграммы деятельности.

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

Состояния действия (action state) - состояние, которое представляет вычисление атомарного действия, как правило - вызов операции. Состояния действия не могут быть подвергнуты декомпозиции. Они атомарны, то есть внутри них могут происходить различные события, но выполняемая в состоянии действия работа не может быть прервана. И наконец, обычно предполагается, что длительность одного состояния действия занимает неощутимо малое время. Действие может заключаться в вызове другой операции, посылке сигнала, создании или уничтожении объекта либо в простом вычислении - скажем, значения выражения.

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

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

Переход (Transitions) - отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока и используются переходы, показывающие путь из одного состояния действия или деятельности в другое. В UML переход представляется простой линией со стрелкой.

Ветвления. Простые последовательные переходы встречаются наиболее часто, но их одних недостаточно для моделирования любого потока управления. Как и в блок-схему, в диаграмму деятельности может быть включено ветвление или множественный переход со сторожевыми условиями. Ветвление описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. Графически точка ветвления представляется ромбом. В точку ветвления может входить ровно один переход, а выходить - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится.

Разделения и слияния. Простые и ветвящиеся последовательные переходы в диаграммах деятельности используются чаще всего. Однако часто возникает потребность изображения параллельных потоков, и это особенно характерно для моделирования бизнес-процессов. В UML для обозначения разделения и слияния таких параллельных потоков выполнения используется синхронизационная черта, которая рисуется в виде жирной вертикальной или горизонтальной линии. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих, слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий. [1]

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

· аппаратное обеспечение;

· программное обеспечение;

· маркетинговые расходы;

· расходы на сопровождение системы (содержание дополнительного персонала, обучение, поддержание работоспособности сервера) можно разделить на две части: клиентское и серверное (собственно компьютер электронного магазина). Клиентские компьютеры -- это, как правило, недорогие персоналки, оснащенные средствами мультимедиа. Собственно компьютеры электронного магазина -- это мощные и надежные компьютеры, организующие продажу товаров и/или услуг [15]. Иногда для создания электронного магазина достаточно модернизировать имеющиеся аппаратные средства организации: увеличить быстродействие сервера баз данных, установить более мощный шлюз или арендовать более емкий канал с целью увеличения пропускной способности. Часто этим обойтись не удается, и организации приходится приобретать новое оборудование. В электронной коммерции можно использовать как универсальное, так и специализированное оборудование.

Несколько слов об оборудовании второго вида.

Для крупнейших предприятий могут подойти серверы web-коммерции. Цены на серверы довольно высоки и составляют сотни тысяч долларов. Эти серверы имеют средства для интерактивной идентификации и проверки полномочий клиента, обработки заказов и платежей, контроля заказов и их статуса, а также обслуживания клиентов. Средние предприятия могут себе позволить приобрести аппаратно-программное обеспечение для создания и эксплуатации сервера электронной коммерции. Услуги защиты, управления информационным наполнением и контроля заказов, предоставляемые этим компонентом, обойдутся заказчику в несколько тысяч долларов плюс ежемесячная доплата порядка такой же суммы. Предприятиям из сферы малого бизнеса предназначено семейство продуктов InBusiness (корпорация Intel). Это семейство содержит переключаемые 10/100 Мбит/с концентраторы, коммутаторы и интернет-станции, позволяющие осуществлять онлайновую торговлю в Интернете без web-сервера.

На отечественном рынке наибольшее распространение получили

«коробочные» (комплексные, готовые к непосредственному применению) решения, купив которые, можно относительно быстро и дешево организовать инфраструктуру виртуального магазина. К наиболее известным в России иностранным программным продуктам для электронной коммерции этого класса можно отнести Intershop 3 (компании Intershop) и Microsoft Merchant Server, входящий в состав Microsoft Site Server/ Commerce Edition. Оба продукта используют SQL_версии баз данных: Sybase SQL Server и Microsoft SQL Server соответственно. В числе других зарубежных программных продуктов для электронной коммерции, присутствующих на российском рынке, можно назвать Oracle Internet Commerce Server (фирма Oracle), комплект для организации электронной коммерции CommerceXpert (фирма Netscape Communications), а также пакет программ от фирмы Raima[16].

Среди отечественных программных продуктов названного типа «1С: Аркадия Интернет-магазин». Достоинством этого продукта является то, что в качестве базы данных онлайн-торговли он использует популярный программный продукт для организации управления торговой деятельностью «1С: Торговля и склад» компании «1С». Также отечественное программное обеспечение «Формоза-Софт», «АйТи», «Гарант Парк», Quarta.



Заключение

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

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

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

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

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

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

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

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



Список используемой литературы

• 1. Калянов Г.Н. CASE структурный системный анализ. -- М.: ЛОРИ, 1996.
• 2. Мазный Г.Л., Савватеева Т.П. Теория и технология проектирования. -- Дубна, 2003.

3. Емельянова Н.З., Партыка Т.П., Попов И.И. Проектирование информационных систем. -- М.: ФОРУМ, 2009.

4. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. -- М.: Финансы и статистика, 1998.

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

...