Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML»

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Целью курсовой работы является создание UML модели взаимоотношений с клиентами.

Глава 1. Анализ технологии решения задачи

1.1.1  Описание предметной области. Постановка задачи

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

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

-        Обработка входящего заказа с сайта

-        Обработка заявки «обратного звонка» с сайта

-        Прием входящих звонков от клиентов

-        Информирование клиентов обо всем, что связано с покупкой в интернет - магазине

-        Предложение дополняющих товаров в рамках телефонного разговора

-        Сбор информации о клиенте

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

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

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

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

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

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

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

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

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

      1. Задачи проекта
  • Построить диаграмму вариантов использования (диаграмма прецедентов);
  • Построить диаграмму последовательности по решаемой задаче;
  • Построить диаграмму состояний по решаемой задаче;
  • Построить диаграмму деятельности по решаемой задаче;
  • Построить диаграмму классов по решаемой задаче.

1.1.2 Сотрудники и их функционал

Рассмотрим понятие отношений с покупателями.

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

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

  • КОНТЕНТ-МЕНЕДЖЕР
  • Ведение базы поставщиков
  • Поиск ошибок в характеристиках, ценах или фотографиях.
  • Наполнение сайта актуальной информацией.
  • Разработка акций и распродаж.
  • БУХГАЛТЕР
  • Работа с документами и отчетами.
  • Прием оплаты
  • ОПЕРАТОР
  • Отслеживание заказов и их подтверждение.
  • Консультации по телефону.
  • Отслеживание пути заказа, пока он не поступит клиенту.
  • Работа с базой клиентов
  • КЛАДОВЩИК
  • Упаковка товара.
  • Прием товара
  • Инвентаризация
  • Передача курьеру
  • КУРЬЕРЫ
  • Доставка заказов
  • Прием оплаты (наличные или карта)
  • УПРАВЛЯЮЩИЙ
  • Ведение отчетности.
  • Анализ данных
  • Обучение персонала.

1.1.3 Отчеты

Новые отчеты, которые мы сможем получить после усовершенствования системы управления взаимоотношениями с клиентами.

  • Работа с жалобами покупателей;
  • Отчет по новым клиентам;
  • Классификация покупателей;
  • Продажи с картой лояльности клиента ;
  • Отчет по событиям, как мы общались с клиентом и сделал ли он заказ (звонок, встреча, письмо).Статистика;
  • Отчет по проделанной работе.

1.2 Предлагаемые мероприятия по улучшению бизнес-процессов


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

Что еще мы получим от внедрения CRM , помимо указанных выше плюсов:

  • сбор в единую клиентскую базу всей собранной о клиентах информации;
  • сбор истории  отношений с покупателями и партнерами;
  • обмен информацией между подразделениями и работниками;
  • автоматизация бизнес-процессов;
  • получение аналитических отчетов;
  • использование приобретённых познаний в целях маркетинга;
  • разработка эффективной программы лояльности; [3].

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

2.Выбор средства для моделирования предметной области решаемой задачи

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

UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.

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

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

  • диаграммы вариантов использования;
  • диаграммы состояний;
  • диаграммы активности;
  • диаграммы взаимодействия;
  • диаграммы последовательности;
  • диаграмма сотрудничества / кооперативная

Структурные диаграммы отображают элементы, из которых состоит 10 система.

  • диаграммы реализации;
  • диаграммы топологии;
  • диаграммы компонент;
  • диаграммы классов;

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

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

 строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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

2.1 Сравнительный анализ средств моделирования

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

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

В ходе анализа работы компании строится модель «как-есть» (AS-IS). Она демонстрирует все недостатки функционирования исследуемого объекта. На базе модели «как-есть» строится модель «как должно быть» (TO-BE), которая с учетом недостатков модели «как-есть» будет по-новому организовывать деятельность исследуемого объекта. Впоследствии внедрения в работу модели «как должно быть» будут решены поставленные в ходе планирования проекта задачи. К ним может относится: · внедрение программного обеспечения;

· сокращение времени выполнения бизнес-процессов;

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

· повышение качества поставляемых на рынок продуктов/услуг;

· повышение качества обслуживания клиентов и т.д.

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

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

2.1.1.1 Microsoft Visio

Visio - решение для построения диаграмм от Microsoft. По словам 12 разработчиков, Visio помогает преобразовать технические и бизнесконцепции в визуальную форму. И действительно, этот пакет из семейства Microsoft Office предназначен исключительно для рисования диаграмм. Visio имеет некоторые дополнительные возможности, но все же, повторим, по большей мере - это только средство для иллюстрирования документов MS Office, "не дотягивающее" до уровня пакетов, которые мы описывали ранее.

 Изобразительные же возможности Visio действительно весьма широки:  Используя предопределенные фигуры Visio Professional , drag-and-drop и мастера, вы можете быстро и просто создавать понятные и информативные диаграммы.

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

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

 Можно легко рисовать диаграммы сетевых ресурсов, иллюстрирующие развертывание нового ПО на существующие сетевые ресурсы.

 Visio Professional также тесно интегрируется с Microsoft Office Project, что позволяет, например, импортировать оттуда задачи для членов команды.

 С помощью шаблонов UML вы можете создавать UML-диаграммы статической структуры ПО или проводить обратное проектирование с помощью Visio 2003 Reverse Engineer Wizard.

 Visio 2003 может документировать для вас структуру существующих веб-сайтов, помогая таким образом в разработке, реализации или интеграции веб-приложений.

 Можно также создавать отчеты, сохранять диаграммы как вебстраницы и еще многое-многое другое... Отметим, что Visio - это не полноценное средство моделирования, а программа для создания иллюстраций, умеющая, кроме прочего, рисовать UML-диаграммы[6]

2.1.1.2 BPWin

BPwin Относится к категории CASE средств верхнего уровня. BPwin является достаточно развитым средством моделирования, позволяющим проводить анализ, документирование и улучшение бизнес процессов. С его помощью можно моделировать действия в процессах, определять их порядок и необходимые ресурсы. Модели BPwin создают структуру, необходимую для понимания бизнес процессов, выявления управляющих событий и порядка взаимодействия элементов процесса между собой. BPwin поддерживает функциональное моделирование, моделирование потока работ и потока данных. Соответствующие диаграммы реализованы на основе стандартов IDEF0, IDEF3 и DFD.

Разработка моделей требует четкого понимания всех аспектов бизнес процессов. CASE средство должно позволять моделировать действия процесса, порядок их исполнения и контроля, состав ресурсов и информации, состав входов и выходов процессов, а также давать возможность документировать полученные результаты. BPwin 7, в той или иной степени, выполняет все эти задачи. [7]

2.1.1.3 CaseBerry

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

Традиционно, преимуществами проектирования в UML называют:

 собственно моделирование, дающее ясное понимание предметной области и возможностей по улучшению бизнеса, а также соответствующих этому требований к программному обеспечению;

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

 наглядность — служит универсальным «мостиком» между предметными специалистами и разработчиками;

 сокращение цикла разработки приложений;

 увеличение продуктивности работы программистов за счёт чёткой спецификации, значительное упрощение и автоматизация процесса проектирования;

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

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

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

 Поддерживает все диаграммные методы нотации UML;

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

2.1.1.4 IBM Rational Rose

CASE-средство IBM Rational Rose со времени своего появления претерпело серьезную эволюцию, и в настоящее время представляет собой современный интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем. Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария.

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

Rational Rose объединяет команду разработчиков на базе универсального языка моделирования UML, который определяет стандартную графическую символику для описания архитектуры ПО. Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут 16 использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта.[9]

2.1.1.5 StarUML

StarUML - программная платформа моделирования, которая поддерживает UML (Унифицированный Язык Моделирования . Поддерживает нотацию UML версии 2 и одиннадцать различных типов диаграмм. Она активно поддерживает подход MDA (Архитектура Управляемая Моделью) и концепцию профилей UML. StarUML превосходен в отношении настройки окружения пользователя и имеет высокую степень расширяемости в том, что касается его функциональных возможностей.

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

StarUML™ может также быть интегрирован с любыми внешними инструментальными средствами.[10]

Исходя из анализа существующих средств моделирования, выбор сделан в пользу IBM Rational Rose, CaseBerry, Microsoft Visio. Ведущими причинами, повлиявшими на выбор, являются наличие бесплатной версии, простота применения, возможность обрисовывать модели в нотации языка UML. Связь Caseberry с СУБД MS SQL Server комфортна, но требует огромных усилий, чтобы корректно настроить СУБД для работы с CASE- средством. Окончательный выбор был сделан в пользу Visio так как нравится творческий подход к созданию диаграмм.

Глава 2. Проектирование предметной области

2.1 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Построим объектно-ориентированную модель на основе бизнес-модели организации. Для этого будем пользоваться программным средством MS Visio и опишем разрабатываемую систему при помощи языка UML.

2.2.1 Диаграмма вариантов использования

Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. [11]

Описание элементов диаграммы:

  • Контент-менеджер – разрабатывает промоакции для привлечения клиентов, заполняет вебсайт информацией для клиента;
  • Покупатель – Смотрит каталог товаров на сайте ,выбирает нужный, оформляет заказ, оплачивает заказ ;
  • Оператор – Оформляет карточку покупателя для ( возраст, ФИО, адрес) отмечает важные сведения о покупателе( не любит красный цвет, плохой опыт использования румян и т.д.), предлагает дополнительные товары, помогает в дальнейшем оформлении заказа, отправляет информацию кладовщику ;
  • Кладовщик – Ведет учет товаров, собирает поступившие заказы , выдает заказ курьеру;
  • Курьер – Получает заказ от кладовщика и доставляет его клиенту, если оплата наличными, то получает оплату и передает ее в бухгалтерию;
  • Бухгалтерия – Получает оплату по безналичной оплате от клиента или за наличный расчет через курьера.
  • Управляющий – Получает отзыв от клиента.

На рисунке 1 представлена диаграмма вариантов использования.

Рисунок 1. Диаграмма вариантов использования.

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

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

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

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

  • Управляющий изучил слабые места операторов;
  • Управляющий провел тренинг с операторами и выдал скрипты;
  • Клиент оформил заказ на сайте;
  • Оператор получил информацию о поступившем заказе;
  • Оператор запросил в базе клиентов информацию о клиенте;
  • База выдала данные о клиенте;
  • Оператор связался с клиентом;
  • Оператор уточнил дополнительную информацию у клиента;
  • Оператор внес изменения в базу клиентов;
  • Оператор сделал индивидуальное предложение клиенту;
  • Оператор предложил клиенту дополнительные товары;
  • Клиент выбрал дополнительные товары;
  • Оператор уточнил дату доставки у клиента;
  • Клиент оплачивает заказ картой ;
  • Бухгалтерия принимает оплату;
  • Оператор передает информацию о заказе кладовщику;
  • Кладовщик собирает заказ;
  • Кладовщик оправляет информацию о готовности заказа в базу клиентов;
  • Кладовщик передает заказ курьеру;
  • Курьер доставляет заказ;
  • Клиент оплачивает заказ наличными;
  • Клиент оставляет отзыв управляющему;
  • Курьер передает наличные в бухгалтерию;
  • Курьер передает документы по заказу кладовщику;
  • Управляющий дает обратную связь по отзыву клиента оператору;

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

Рисунок 2. Диаграмма последовательности по решаемой задаче.

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

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

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

  • Поступает звонок от клиента;
  • Клиента соединяют со свободным оператором;
  • Если клиент постоянный его ищут в CRM и если есть делают индивидуальное предложение;
  • Если клиент новый, то вносят данные о клиенте в базу CRM;
  • Любому из клиентов предлагается дополнительная продукция;
  • Если клиент согласен на товары, то оператор подбирает дополнительные товары;
  • Если клиент отказался от дополнительных товаров, то сразу переходим к оплате;
  • Клиент выбирает вариант оплаты (карта или наличные);
  • Если товар есть в наличии, то совершается сборка товара;
  • Затем совершается доставка товара;
  • Если товара нет, то соединяем клиента с оператором;
  • Клиент может отказаться от товара;
  • Клиент может принять решение на изменение или добавление других товаров в заказ;

На рисунке 3 представлена диаграмма состояний

Рисунок 3. Диаграмма состояний.

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

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

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

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

  • Блок покупатель

Звонок в магазин

  • Блок оператор

Соединение с оператором - Звонок клиента принят

Отмена или изменение заказа

Новый клиент – внесение информации в CRM

Постоянный клиент –поиск клиента в CRM – индивидуальное предложение

Предложение дополнительных товаров любому из клиентов - скрипт отработан

Согласие не доп. Товар – подбор товара - заказ оформлен

Отказ от доп. Товара - заказ оформлен

  • Блок бухгалтерия

Прием оплаты картой от клиента

Прием оплаты наличными через курьера

  • Блок склад

Сборка заказа при его наличии

Доставка заказа

На рисунке 4 представлена диаграмма деятельности

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

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

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

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

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

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

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

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

Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++).

Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки. [15]

Описание диаграммы классов:

  • Данная диаграмма показывает взаимосвязи между сущностями участвующими в оформлении заказа интернет - магазина.
  • Работники – включает в себя работников магазина участвующих в оформлении заказа клиента интернет - магазина:
  • Управляющий, контент-менеджер, оператор, бухгалтер, работники склада, курьер. Главным атрибутом класса является должность.
  • Контент-менеджер – Работа с сайтом. Главным атрибутом класса является ФИО
  • Управляющий – Обладает правами увольнять и нанимать сотрудников. Полный цикл управления. Главным атрибутом класса является ФИО
  • Оператор – принимает заказ и отправляет информацию в систему для остальных сотрудников. Главным атрибутом класса является
  • Бухгалтер – принимает платежи клиентов и информирует администратора о результате. Главным атрибутом класса является
  • Работники склада – проверяют наличие товара и передают заказ в службу доставки. Главным атрибутом класса является Кладовщик
  • Курьер – принимает заказ от работников склада и доставляет заказ клиенту. Главным атрибутом класса является
  • Товар – перечень всего товара, представленного в интернет – магазине и его цена. Главным атрибутом класса является: наименование товара.
  • Заказ – в заказе указывается номер заказа, дата заказа, состояние заказа, стоимость заказа, статус выполнения и номер клиента. Главный атрибут: ID заказа.
  • Оплата – Чек и вид оплаты. Главным атрибутом класса является ID транзакции

На рисунке 5 представлена диаграмма классов

Рисунок 5. Диаграмма классов.

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

  1. Технологии CRM. Экспресс-курс, Молино П., Переводчик: Татьяна Новикова,, 272 с.
  2. http://www.itproject.ru (дата обращения 05.08.19)
  3. Проектирование программного обеспечения экономических информационных систем: Вендров А.М. Учебник, 2006. — 544
  4. Разработка метода поведения сравнительного анализа языков бизнес-моделирования , Э.А. Бабкин, В.П. Князькин, М.С. Шиткова, 2010
  5. Объектно-ориентированные CASE-средства. https://studbooks.net (дата обращения 10.08.2019)
  6. Введение в UML. https://www.intuit.ru (дата обращения 10.08.19)
  7. CASE-средства .Учебно-методическое пособие. - 2007. - 88 с. Тебайкина Н.И.
  8. https://caseberry.net/ (дата обращения 10.08.2019)
  9. http://www.interface.ru (дата обращения 10.08.2019)
  10. Руководство пользователя © Перевод Д. В. Летуновского, 2007
  11. UML Основы. Мартин Фаулер. Перевод А. Петухова.2005 192 с.
  12. Язык UML. Руководство пользователя — Гради Буч, Джеймс Рамбо, Ивар Якобсон 2007
  13. Российский экономический университет имени Г. В. Плеханова Unified Modeling Language (UML) - унифицированный язык моделирования. к.т.н.,доцент Горбенко А.О.
  14. Моделирование на UML. Учебно-методическое пособие, Денис Иванов и Федор Новиков.
  15. Самоучитель UML. Леоненков Александр 418.c 2004