Создание проекта информационной системы электронной торговли

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

Министерство образования и науки Республики Таджикистан

Политехнический институт Таджикского технического университета

имени академика М. Осими в г. Худжанде

Факультет: "Информационно-технологический"

Кафедра: "Информационные системы и экономика"

"Утверждаю"

Зав. кафедрой "ИС и Э"

Худойбердиев Х.А.

Курсовая работа

Создание проекта информационной системы электронной торговли

Выполнил:

Расулов Азимджон Абдуазизович

студент 4 курса

группы 40.01.02ра

Худжанд - 2015



Содержание

Введение

1. Этап анализа

1.1 Описание предметной области

1.2 Определение процессов

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

1.4 Типичный ход событий

1.5 Концептуальная модель

1.6 Определение основных функций системы

1.7 Диаграмма последовательностей

2. Этап проектирования

2.1 Системных операций

2.2 Реальные прецеденты с интерфейсными формами

2.3 Диаграмма кооперации

2.4 Распределение обязанностей между классами

2.5 Диаграмма состояний

2.6 Диаграмма классов

2.7 Диаграмма развертывания

3. Расчет себестоимости ИС

3.1 Калькуляция весовых действующих лиц

3.2 Калькуляция весовых вариант использования

3.3 Определение уровень технический сложности проекта

3.4 Определение уровень квалификации разработчиков

3.5 Оценка трудоемкости проекта

Заключение

Список литературы

Приложение

Введение

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

Основными направлениями деятельности в области электронной торговли являются:·развитие информационного бизнеса, электронной коммерции и маркетинга на основе Интернет.

Данная работа состоит из 40 страниц, 16 рисунков, 26 таблиц и три глав.

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

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

В третьей главе описывается калькуляция "разработки электронной торговли.



1. Этап анализа

1.1 Описание предметной области

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

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

Функции электронной торговли:

· предоставление онлайновой помощи покупателю;

· регистрация покупателей;

· предоставление интерфейса к БД продаваемых товаров (в виде каталога, прайс-листа);

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

· оформление заказов с выбором метода оплаты, доставки, страховки и выпиской счёта;

· резервирование товаров на складе;

· проведение расчётов (при выборе электронных методов оплаты) или контроль факта оплаты (при использовании традиционных форм расчётов);

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

· предоставление покупателю средств отслеживания исполнения заказов;

· доставка товаров;

· сбор и анализ различной маркетинговой информации;

· обеспечение безопасности личной информации покупателей;

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

1.2 Определение процессов

Перед началом моделирования, разработчику стоит определиться с двумя важными вещами:

Во-первых, необходимо зафиксировать цель моделирования процесса, то есть ответить на вопросы, что должна отражать модель.

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

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

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

Далее, собранный материал переводится в символы IDEF0, в соответствии с правилами методики.

Модель электронной торговли раскрывался как сложный модель и состоит из 11 процессов. Этот модель показано ниже на рисунке 1.1

Рис 1.1 . Декомпозиция бизнес-процесса электронной торговли на составляющие его операции в стандарте IDEF 0

Таблица 1.1 Описание процессов

P1=регистрация пользователя; I1=ввод данные; M1= регистрация и авторизация; C1=система; O1=логин и пароль;	Р5= добавить товар для продажи; I5=данные товара; М5=управление поведение пользователей и их контроль доступа; С5=система; О5=публикация товара;
P2=авторизация пользователя ; I2=логин и пароль; M2= регистрация и авторизация; C2=система; О2=вход на сайт;	Р6=просмотр товара; I6=id_product; М6= управление поведение пользователей и их контроль доступа ; С6=система; О6=информация о товаре;
Р3= изменение профиля; I3=ввод логин и пароль; М3=проверка логин и пароля; С3=система; О3=новые данные;	Р7= комментария просмотренных товаров; I7=id_product; id_user ввод отзывов М7=управление поведение пользователей и их контроль доступа; С7=система; О7=комментария к товару ;
Р4= просмотр каталога; I4=вход в систему; М4=управление поведение пользователей и их контроль доступа; С4=система; О4=просмотр;	Р8=голосование продукта; I8=id_product; id_user; М8=управление поведение поль- зователей и их контроль доступа; С8=модератор; О8=проголосован продукт.
Р9=заказа товара I9=id_product; id_user; vremya; kolichestvo; summa. М9=управление поведение пользователей и их контроль доступа; С9=система; О9=товар заказан;	Р10=оплата товара I9= id_user; id_oplata М9= законодательство заказов, оплата и доставка товаров; С9=система; О9=сумма снято со счета и оплачено

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

Диаграмма в UML -- диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

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



Рис. 1.4 диаграмма прецедентов

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

Таблица 1.2 Описание варианта использования "добавление товара"

Название Прецедента:	Добавление товара
Исполнители:	Поставщик (клиент) и Администратор
Цель:	Добавление товара со стороны поставщиков для публикации товара.
Основной успешный сценарий:	Поставщик добавить товар в нужный каталог и этот товар проверяется со стороны администратора и потом публикуется
Тип:	Идеальный
функция:	Add_product;



Рис. 1.2 процесс добавление товара

Таблица 1.3 Описание варианта использования "заказ-онлайн"

Название прецедента:	Заказ-онлайн
Исполнители:	Покупатель (клиент)
Цель:	Заказ - товаров через сеть интернет в ИС электронной торговли.
Основной успешный сценарий:	Покупатель заходить в ИС и открывает нужный ему каталог, выбирает нужный товар и потом оформит заказ.
Тип:	Идеальный
функция:	Select_catalog; select_product, add_cart

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

1.4 Типичный ход событий

Типичный ход событий - обеспечивает наглядное представление общения с системой.

Таблица 1.4 типичный ход события "Оформление заказа"

Действия актеров	Отклик
1.Покупатель выбирает товар и отмечает ее как покупаемую	2.Система добавляет код товара в корзину покупателя
3.Покупатель оформляет корзину как заказ	4.Менеджер регистрирует номер заказа, дату и др.реквизиты, подает сигнал о заявке менеджеру продаж
5.Покупатель вводит номер карты скидок магазина	6.Менеджер проверяет номер
7.Покупатель оплачивает товар удобным для него способом	8.Менеджер продаж проверяет платеж и отправляет письмо с подтверждением платежа покупателю

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

1.5 Концептуальная модель

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

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

Таблица 1.5. Список категорий концептуальных классов

Категория концептуальных классов	Примеры
Транзакции Рекомендации: эти классы особенно критичны, поскольку зачастую описывают финансовые операции, поэтому процесс выделения концептуальных классов следует начинать именно с них	customer ( покупатель), product(товар), zakaz (заказ), oplata(оплачивание)
Элементы транзакций Рекомендации: транзакции зачастую состоят из элементов	Zakaz(товар) Product(товары)
Товары или службы, связанные с транзакциями или их элементами Рекомендации: транзакции выполняются над некоторыми элементами (товарами или службами)	Product-korzina ; korzina-zakaz
Роли людей или организации, связанные с транзакциями. Исполнители прецедентов Рекомендации: необходимо знать, кто участвует в транзакции	Customer (Покупатель), seller (поставщик), admin (администратор),
Место транзакций	Product; zakaz; oplata
Важные события, для которых необходимо хранить время и место	Zakaz; oplata
Физические объекты Рекомендации: такие объекты обычно соответствуют программным системам, предназначенным для управления или моделирования	Catalog(каталог), product (Товар),
Описание объектов	Catalog-product(Каталог товаров) product-characteristika
Каталоги Рекомендации: описание зачастую приводится в каталоге	ProductDescription (Каталог товаров) FlightDescription (Каталог рейсов)
Контейнеры других объектов (физических или информационных)	Oplata
Содержимое контейнеров	Customer; product
Другие системы, внешние по отношению к данной системе	Oplata; web-oplata; bankovskie_kartochki

Ассоциация (association) - это отношение между классами, отражающая некоторые значимые и полезные связи между ними. Ассоциация обозначается проведенной между классами линией, с которой связано определенное имя, начинающееся с большой буквы. На рисунку 5 приведен пример ассоциации.

Рис. 1.5. Система обозначений ассоциаций в языке UML.

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

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



Таблица 1.6. Список стандартных ассоциаций

Категория	Примеры
А является транзакцией, которая связана с другой транзакцией В	product-korzina( товар-корзина); korzina-zakaz(корзина-заказ)
А является элементом транзакции	Product(товар)
А является товаром или услугой для транзакции В	Product- zakaz(товар- заказ)
А является ролью, связанной с транзакцией В	Customer-oplata (ПокупательПлатеж) Product- zakaz(товар- заказ)
А является физической или логической частью В	Customer-zakaz (покупатель-заказывает)
А физически или логически содержится в В	Catalog-product(каталог-товар) Product-characteristika (Товар-описание товара)
А является описанием В	Product-characteristika (Товар-описание товара)
А известен/зарегистрирован/ записан/включен в В	Zakaz-autorize(заказ товара-авторизация покупателя) zakaz-oplata (опаливание-заказ товара)
А является членом В	Product-catalog (товар-каталог)
А является организационной единицей В	Users-(vneshniy user; vnutrenniy user); Vneshniy user-(customer; seller)
А использует, управляет или владеет В	Customer-product; Seller-product
А следует за В	SalesLineItem- SalesLineItem (Наименование товара- Следующее наименование товара)

Функциональность и эффективность информационной системы - является одним из основных требований в разрабатываемой квалификационной работе.

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

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

Рис. 1.5 диаграмма классов электронной торговли

На рис. 1.5 показана концептуальная модель. В ней выделены 5 основных концептуальных классов: "Users", "Product", "Zakaz", "Oplata" и "Korzina". Эти классы в свою очередь разделятся на несколько классов которые приведены ниже на рисунке 1.5

Каждый класс имеет свои атрибуты и операции.

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

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

Полноценность и достоверность информации - так же одно из наиболее важных требований к разрабатываемой теме.

Диаграмма классов - это та диаграмма, которая позволяет структурно описать проектируемую тему, показать ее основные структурные блоки, отношения между ними.

1.6 Определение основных функций системы

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

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

Таблица 1.7. Описания функций ИС электронной торговли

№	Функции	Тип
1.	Регистрация покупателя на сайте	Скрытая
2.	Авторизация покупателя	Скрытая
3.	Приём заказов (от зарегистрированных покупателей)	Скрытая
4.	Регистрация нового товара	Очевидная
5.	изменение информации (переоценка или изменение других атрибутов)	Очевидная
6.	Приём заказов (от зарегистрированных покупателей)	Очевидная
7.	удаление информации (при списании или продаже последней книги)	Скрытый
8	Добавить товар	Очевидная
9	Удалить товар	Очевидная
10	Представить корзину	Очевидная
11	Калькуляция одного товара	Очевидная
12	Суммарная калькуляция	Очевидная
13	Редактирование комментарии клиентов	Скрытая
14	Верификация товаров на сайте	Скрытая я
15	Мониторинг	Очевидная
16	учет новостей и реклам на сайте	Очевидная
17.	Web-оплата	Скрытая
18.	Получение остатка	Очевидная

1.7 Диаграмма последовательностей

Диаграмма последовательности - одна из диаграмм взаимодействия. На диаграмме последовательностей иллюстрируются события, инициированные в системе исполнителями.

Моделирование временной упорядоченности потока управления осуществляется следующим образом:

1. Устанавливается контекст взаимодействия, будь то система, подсистема, операция, класс или один из сценариев прецедента либо кооперации.

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

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

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

Рис 1.6. Диаграмма последовательности прецедента онлайн-заказ.

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



2. Этап проектирования

Для разработки данного ИС используется PHP & MYSQL потому что РНР предоставить программисту средства для быстрого и эффективного решения поставленных задач. Практический характер РНР обусловлен пятью важными характеристиками:

* традиционностью;

* простотой;

* эффективностью;

* безопасностью;

* гибкостью.

Существует еще одна "характеристика", которая делает РНР особенно привлекательным: он распространяется бесплатно! Причем, с открытыми исходными кодами ( Open Source ).

Сценарии на языке PHP могут выполняться под всеми основными операционными системами, в том числе под Microsoft Windows и Unix-подобными операционными системами (Linux, OpenBSD, Solaris, HP-UX), Mac RISC OS, OS X и некоторыми другими. Большинство современных веб-серверов поддерживают PHP: Apache, Personal Web Server, Microsoft Internet Information Server, iPlanet, Netscape, Caudium, Oreilly Website Pro, OmniHTTPd, Xitami и другие.

Язык PHP позволяет организовать обработку данных форм, создание динамических страниц сайта, создание и обработку файлов cookies и многие другие функции CGI (Common Gateway Interface).

Язык сценариев PHP позволяет вести разработку приложений как на основе процедурного, так и на основе объектно-ориентированного программирования (ООП).



2.1 Системных операций

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

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

Таблица 2.1. Описание системной операции register_customer

Операция	register_customer
Ссылки	Прецедент регистрации покупателя
Предусловие	Вводится данные пользователя ФИО; адрес; номер телефона.
Постусловие	Зарегистрирован пользователь

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

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



Таблица 2.2. Описание системной операции autorize

Операция	Authorize
Ссылки	Прецедент авторизация покупателя
Предусловие	Вводится login и password пользователя.
Постусловие	Вход на сайт

Таблица 2.3. Описание системной операции add_product

Операция	Add_product
Ссылки	Прецедент Регистрация нового товара
Предусловие	Вводится name_product, price, image, description.
Постусловие	Зарегистрировано товар

В этом операции пользователи-поставщики могут зарегистрировать новые товары, заполняя данные товары которые приведены в таблице №2.3.

Таблица 2.4. Описание системной операции update_product

Операция	Update_product
Ссылки	Прецедент редактирование товара
Предусловие	Id_product; name_product, price, image, description.
Постусловие	товар редактирован

В этом операции пользователи-поставщики могут редактировать данные товара.

Таблица 2.5. Описание системной операции delete_product

Операция	delete_product
Ссылки	Прецедент редактирование товара
Предусловие	Id_product; name_product.
Постусловие	Товар удален

Если товар на складе в наличии не осталось, то с помощью данной операции, поставщик может удалить товар.



Таблица 2.6. Описание системной операции search-product

Прецедент	search-product
Ссылки	Поиск и выбор товара
Предусловие	Id_product; name-product; id_catalog; name_catalog.
Постусловие	Найдено товар.

С помощью данной операции пользователи могут найти товар и по форме поиска и по каталогу.

Таблица 2.7. Описание системной операции zakaz_product

Прецедент	Zakaz_product
Ссылки	Оформление заказа на выбранный товар
Предусловие	Id_product; name_product; id_pokupatel; date_zakaz; kolich_product; price_product; summa_zakaz.
Постусловие	Оформлен заказ

После выбор товара пользователи могут, оформит онлайн-заказ.

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

2.2 Реальные прецеденты с интерфейсными формами

Таблица 2.8 Описание варианта использования "добавление товара"

Название прецедента	Добавление товара
Исполнитель	Поставщик (продавец)
Цель	добавление продукта к системе от лица поставщика чтобы опубликовать и продать данный товар.
Описание	Поставщик открывает свой интерфейс и добавляет товар в необходимый каталог. Далее этот продукт проходить верификацию со стороны администратора, после утверждение этот продукт идет на публикацию
Тип	Идеальный
Ссылки	Функции:addproduct to catalog; edit_product, delete_product



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

бизнес интернет информационный торговля

Рис. 2.1 процесс добавление товара

Этот процесс управляется администраторам ИС то есть проверяет данные о товаре и поставщиков и потом этот товар публикуется в ИС "электронной торговли"

Таблица 2.9 Описание варианта использования "заказ-онлайн"

Название Прецедента:	Заказ-онлайн
Исполнители:	Покупатель (клиент)
Цель:	Заказ - товаров через сеть интернет в ИС электронной торговли.
Основной успешный сценарий:	Покупатель заходить в ИС и открывает нужный ему каталог, выбирает нужный товар и потом оформит заказ.
Тип:	Идеальный
функция:	Функции: oder product by id; Cart_user; listProducts

Рис. 2.2 процесс оформление заказа



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

Рис. 2.3 диаграмма прецедентов

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

2.3 Диаграмма кооперации

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

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

Сравнительная характеристика диаграмм взаимодействия приведена в таблице 2.10.

Таблица 2.10. Сравнительная характеристика типов диаграмм взаимодействия

Тип диаграммы	Преимущества	Недостатки
Последовательностей	Ясно отображает последовательность и временной порядок сообщений. Богатый набор обозначений.	Расширяется вправо при добавлении новых объектов; занимает много места по горизонтали.
Кооперации	Экономия пространства - возможность добавления объектов в двух направлениях.	Сложнее отследить последовательность сообщений. Более бедная система обозначений.

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

Рис. 2.4 - Диаграмма последовательности онлайн-заказ.

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



Рисю 2.5 диаграмма кооперации электронной торговли

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

2.4 Распределение обязанностей между классами

Таблица 2.11. Краткое описание шаблонов распределения обязанностей

№	Шаблон	Описание	Класс
1.	Information Expert	За выполнение обязанности должен отвечать информационный эксперт - класс, имеющий информацию, которая необходима для выполнения этой обязанности	administrator
2.	Creator	Классу Customer назначается обязанность по созданию экземпляров класса Users, если выполняется одно из следующих условий. * Класс Customer содержит объекты Users * Класс Customer агрегирует объекты Users * Класс Customer обладает данными инициализации для объектов Users * Класс Customer записывает экземпляры объектов Users * Класс Customer активно использует объекты Users	user
3.	controller	Выполнение системных операций должен координировать (контролировать) класс, не относящийся к уровню интерфейса пользователя и удовлетворяющий одному из следующих условий. * Класс представляет всю систему, корневой объект, устройство или подсистему в целом (внешний контроллер) * Класс представляет некоторый сценарий прецедента, в процессе выполнения которого выполняются системные операции (контроллер прецедента или контроллер сеанса)	Zakaz
4.	Low Coupling	Чтобы снизить влияние изменений, обязанности должны распределяться таким образом, чтобы степень связанности оставалась низкой.	Administrator
5.	Polymorphism	Если поведение объектов одного типа (класса) может изменяться, обязанности распределяются для различных вариантов поведения с использованием полиморфных операций для этого класса	Product и characteristics
6.	Pure Fabrication	Если у разработчика возникли проблемы, как можно обеспечить реализацию шаблонов High Cohesion и Low Coupling, создается искусственный класс, не представляющий конкретного понятия из предметной области, т.е. синтезируется искусственная сущность для поддержки высокого зацепления.	customer, seller

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

2.5 Диаграмма состояний

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

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

Рис 2.6 Диаграмма состояние товара на сайте

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

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

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

2.6 Диаграмма классов

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

Рис 2.7 диаграмма классов электронной торговли

Они иллюстрируют взаимоотношения программных элементов, а не понятий из предметной области. На рисунке 2.7 приведен пример диаграммы классов для электронной торговли.



Рис. 2.8 диаграмма компонентов

Диаграмма компонентов служит частью физического представления модели, играет важную роль в процессе ООАП и является необходимой для генерации программного кода. Для разработки диаграмм компонентов в браузере проекта предназначено отдельное представление компонентов (Component View), в котором уже содержится диаграмма компонентов с пустым содержанием и именем по умолчанию Main (Главная)

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

2.7 Диаграмма развертывания

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "размещение" точнее отражает сущность этого типа диаграмм.

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

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

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

Рис. 2.9. Диаграмма развертывания

В седьмом разделе было проектировано диаграмма развертывание. Этот вид диаграмм предназначен для анализа аппаратной части системы.



3. Расчет себестоимости ИС

3.1 Калькуляция весовых действующих лиц

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

Таблица 3.1. Весовые коэффициенты действующих лиц.

Тип действующего лица	Весовой коэффициент
Простое	1
Среднее	2
Сложное	3

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

Таблица 3.2. Типы действующих лиц

Действующее лицо	Тип
Администратор по сбыту	Простое
Программист	Сложное
Модератор	Простое
Дизайнер	Среднее
Аналитик	Среднее
Покупатель	Среднее
Поставщик	Среднее



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

Таким образом, общий весовой показатель равен:

А=2*1 + 4*2+1*3 =13

3.2 Калькуляция весовых вариант использования

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

Таблица 3.3 Весовые коэффициенты вариантов использования

Тип вариант использования	Описание	Весовой коэффициент
Простой	3 или менее транзакций	5
Средний	От 4 до 7 транзакций	10
Сложный	Более 7 транзакций	15

Для системы электронной торговли сложность вариантов использования определяется следующим образом (табл. 3.4).

Таблица 3.4. Сложность вариантов использования

Вариант использования	Тип
регистрация пользователей	Простой
авторизация пользователей	Простой
изменение профиля	Средний
просмотр каталога	Простой
добавить товар	Средний
просмотр товара	Простой
комментировать просмотренных товаров	Средний
голосование товаров	Средний
заказа товара	Средний
оплата товара	Средний

Таким образом, общий весовой показатель равен:

UC = 5*4 +6 * 10 =80.

В результате получаем показатель UUCP (Unadjusted Use Case Points):

UUCP=A+UC=13+80=93

3.3 Определение уровень технический сложности проекта

Техническая сложность проекта (TCF - Technical Complexity Factor) вычисляется с учетом показателей технической сложности (табл. 3.6). Каждому показателю присваивается значение Тi. в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 - высокую значимость). Значение TCF вычисляется по формуле TCF = 0,6 + (0,01*(STi* Весi)) Таблица 3.6 Показатели технической сложности проекта TCF

Таблица 3.5. Показатели технической сложности проекта TCF

Показатель	Описание	Вес
Т1	Распределенная система	2
Т2	Высокая производительност (пропускная способность)	1
Т3	Работа конечных пользователей в режиме он-лайн	1
Т4	Сложная обработка данных	1
Т5	Повторное использование кода	1
Т6	Простота установки	0,5
Т7	Простота использования	0,5
Т8	Переносимость	2
Т9	Простота внесения изменений	1
Т10	Параллелизм	1
Т11	Специальные требования к безопасности	1
Т12	Непосредственный доступ к системе со стороны внешних пользователей	1
Т13	Специальные требования к обучению пользователей	1

Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 - высокую значимость). Значение TCF вычисляется по формуле:

TCF = 0,6 + (0,01 * (УTi * Весi )

Таблица 3.6. Показатели технической сложности системы электронной торговли

Показатель	Вес	Значение	Значение с учетом веса
Т1	2	3	6
Т2	1	3	3
Т3	1	5	5
Т4	1	3	3
Т5	1	3	3
Т6	0,5	5	2,5
Т7	0,5	5	2,25
Т8	2	2,5	5
Т9	1	1	5
Т10	1	2	5
Т11	1	3	4
Т12	1	5	5
Т13	1	1	1
Сумма	41,75

Вычислим TCF для системы:

TCF = 0,6 + (0,01 * 41,75) = 1,0175



3.4 Определение уровень квалификации разработчиков

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

Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 - F4 0 означает отсутствие, 3 - средний уровень, 5 - высокий уровень. Для показателя F5 0 означает отсутствие мотивации, 3 - средний уровень, 5 - высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 - среднюю, 5 - стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 - средний уровень, 5 - все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 - среднюю сложность, 5 - высокую сложность.

Таблица 3.7. Показатели уровня квалификации разработчиков

Показатель	Описание	Вес
F1	Знакомство с технологией	1,5
F2	Опыт разработки приложений	0,5
F3	Опыт использования ООП	1
F4	Наличие ведущего аналитика	0,5
F5	Мотивация	1
F6	Стабильность требований	2
F7	Частичная занятость	-1
F8	Сложные языки программирования	-1

Для каждого показателю даем значение от 1 до 5. Вычислим EF для системы электронной торговли :

Таблица 3.8. Показатели уровня квалификации разработчиков системы электронной торговли

Показатель	Вес	Значение	Значение с учетом веса
F1	1,5	4	6
F2	0,5	4	2
F3	1	1	1
F4	0,5	4	2
F5	1	5	5
F6	2	2	4
F7	-1	0	0
F8	-1	0	0
?			20

Значение EF вычисляется по формуле:

EF = 1,4 + (-0,03* (УFi * Весi ))

Вычислим EF:

EF = 1,4 + (-0,03*20) = 0.8

В результате получаем окончательное значение UCP (Use Case Points):

UCP = UUCP * TCF * EF = 93 * 1,075* 0.8 = 79,98

3.5 Оценка трудоемкости проекта

Рассмотрим показатели F1-F8 и определим, сколько показателей F1-F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч на одну UCP, если 3 или 4-28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.

Для системы регистрации получаем 20 чел.-ч на одну UCP.

Таким образом, общее количество человеко-часов на весь проект равно



UCP =79,98*20 = 1599,6 ч/ч

UCP =1599,6 ч/ч что составляет около 39,99 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из четырех человек (руководитель программист, дизайнер и аналитик), и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 10,7 недель на весь проект.

Для подсчета заработной платы сотрудников за весь период проекта, были произведены вычисления, показанные на рис. 3.9.

Таблица 3.9. начисление зарплаты сотрудникам электронной торговли

№	Сотрудник	ч/ч	З/п за час	Начисление з/п за проект
1	Руководитель	500	28	14000
2	Программист	400	17	6800
3	Дизайнер	300	14	4200
4	Аналитик	400	17	6800
сумма:	1600	9	31800

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

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



Заключение

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

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

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

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



Список литературы

1. UML основы. М. Фаулер. - СПб.: Символ-Плюс, 2005. - 184 с.

2. Технологии разработки программного обеспечения. С.А. Орлов. - СПб.: Питер, 2002. - 342 с.

3. Дастурамал барои и?рои кор?ои лаборатор? аз фанни технологияи UML. Солиев О.М., Худойбердиев Х.А. (электрон? дар китобхонаи ра?амии ДПДТТ)

4. Дастурамал барои и?рои кор?ои семестр? аз фанни технологияи UML. Худойбердиев Х.А. (электрон? дар китобхонаи ра?амии ДПДТТ)

5. Язык UML. Руководство пользователя. Г. Буч, Д. Рамбо, А. Джекобсон. - СПб.: Питер, 2001. - 325 с.

6. Использование средств Visual Basic.Net в создании информационных систем. Учебное пособие. Мачулина Л.А., Скороходов В.А. - Ростов-на-Дону: 2008. -141 с.

7. Самоучитель UML. Леоненков А.В. -СПб.: БХВ-Петербург, 2006. -432 с.

8. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. Вендров А.М. - М.: Финансы и статистика, 2006. - 192 с.



Приложение

Рис. 3. компонент главного страницы

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