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

Содержание:

ВВЕДЕНИЕ

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

Широкое развитие компьютерной техники и телекоммуникаций позволило собирать, хранить, обрабатывать и передавать информацию в таких объемах и с такой оперативностью, которые были немыслимы раньше. Благодаря новым информационным технологиям производственная и непроизводственная деятельность человека, его повседневная сфера общения поистине безгранично расширяются за счет вовлечения опыта, знаний и духовных ценностей, выработанных мировой цивилизацией. Экономика все в меньшей степени характеризуется как производство материальных благ и все в большей — как создание и распространение информационных продуктов и услуг. Для новой экономики информация становится тем же, чем нефть и ее производные стали для экономики индустриальной: она превращается в «топливо» для приобретения знаний, необходимых в условиях нового века.

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

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

Глава 1. Аналитическая часть

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

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

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

В узком смысле CustomerRelationshipManagement, что с английского переводится как «система управления взаимоотношениями с клиентами», — это программное обеспечение (ПО) для хранения данных о клиентах, автоматизации, контроля и анализа всех процессов взаимодействия с ними. Однако понимание CRM всего лишь как ПО было бы слишком поверхностно. Это целая бизнес - стратегия, направленная на укрепление связей с клиентами для оптимизации их обслуживания, что в конечном итоге приводит к повышению ценности каждого потребителя, а следовательно, к росту конкурентоспособности компании. В эпоху массовых продаж и жестокой конкуренции ориентация экономики на продукт утратила актуальность. Производителей множество, качество товаров и услуг — примерно на одном уровне, так же как и цены. Единственным способом отстроиться от конкурентов стала персонализация, то есть выявление и удовлетворение индивидуальных потребностей клиента.

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

Таблица 1 – Входная и выходная информация

Наименование задачи	Входная информация	Выходная информация	Потребитель информации
Публикация каталогов продукции	Информация о продукции	Каталог	Компания, клиент
Рассылка каталогов клиентам	Каталог	Заказ	Клиент
Приобретение товаров клиентами	Заказ	Накладная	Менеджер компании, клиент
Оформление заказов компанией	Накладная	Чек	Кассир, клиент
Отправка товара клиенту	Товар	Расписка в получении	Менеджер, клиент
Возврат товара клиентом	Товар	Расписка в получении с уплатой издержек	Менеджер, клиент
Заказ товара через Интернет	Информация о продукции	Заказ	Менеджер компании, клиент

Ниже приведены термины и их значения.

Таблица 2 – Термины системы

Термин	Значение
Менеджер 1	Менеджер 1 вносит в базу данных сведенияо новой продукции. Тем самым создавая каталог продукции. И при помощи базы клиентов рассылает всем клиентам новый каталог.
База Каталог	Содержит полную и необходимую информацию о всей продукции фирмы.
База Клиент	Содержит информацию о постоянных клиентах фирмы.
Компания	Сотрудники фирмы, непосредственно работающие с клиентами и заказами продукции.
Клиент	Человек, пользующийся услугами фирмы - покупатель продукции.
Менеджер по отправке	Сотрудник фирмы, работа которого заключается в оформлении отправки товара клиенту.
Менеджер компании	Сотрудник фирмы, который создает новые заказы, изменяет их. Работает непосредственно с клиентами по оформлению заказов.
Бухгалтерская система	Бухгалтерская система, которая выписывает счет на покупку продукции.
Логин (вход в систему)	Набор символов, инициализирующий пользователя

1.2. Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Функциональные возможности – система должна обеспечивать многопользовательский режим работы.

Удобство использования – пользовательский интерфейс должен быть совместимым с Windows.

Надежность – система должна быть в работоспособном состоянии 24 часа в день, 7 дней в неделю, время простоя – не более 10%.

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

Глава 2. Проектная часть

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

На следующем этапе выберем несколько CASE-средств, среди которых будет производиться выбор. В данной работе в процессе анализа будут представлены следующие CASE-средства: BorlandTogether, MSVisio 2007, RationalRose. Все эти продукты поддерживают нотацию UML 2.0.

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

Недостатком в данном CASE - средстве является тот факт, что оно поддерживает не все диаграммы нотации UML 2.0. Еще один минус - это отсутствие технической поддержки пользователей. Но! Большим плюсом является тот факт, что имеется возможность использовать не стандартные графические примитивы.

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

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

Семейство продуктов IBM RationalRose предназначено для разработки приложений на основе UnifiedModelingLanguage (UML). Архитекторы, аналитики, проектировщики программного обеспечения и баз данных и разработчики систем могут использовать это семейство продуктов для создания визуальных моделей архитектуры программного обеспечения, баз данных, требований приложения и многоразовых ресурсов, а также определения связи на уровне руководства.

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

Являясь объектно - ориентированным инструментом моделирования, RationalRose базируется на UML (UniversalModelingLanguage) – универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

• Activitydiagram (диаграммы описаний технологий, процессов, функций);
• Use case diagram (диаграммыфункций);
• Classdiagram (диаграммы классов);
• Statediagram (диаграммы состояний);
• Sequencediagram (диаграммы последовательностей действий);
• Collaborationdiagram (диаграммы взаимодействий);
• Componentdiagram (диаграммы компонент);
• Deploymentdiagram (диаграммы топологии).

Основополагающими элементами языка UML являются сущности, отношения и диаграммы.

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

К таким аспектам относятся (Рисунок 1):

Рисунок 1. Аспекты процессов в RationalRose

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

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

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

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

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

CASE - средство RationalRose является коммерческой разработкой компании IBM. Последняя 2007 версия данного продукта поддерживает нотацию UML 2.0 в полном объеме. При инсталляции пакета разработчику предоставляется множество утилит и сопутствующих продуктов, облегчающих разработку систем. Также в пакете присутствует возможность генерации исходного кода приложения на основе моделей. Среди достоинств еще можно выделить очень красивый интуитивно понятный и эргономичный интерфейс продукта.

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

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

Действующими лицами являются:

• Клиент, менеджеры, кассир – конечные пользователи.
• Менеджеры – формируют заказы, составляют каталог, принимают заказы через интернет.

Бухгалтерская система – оформляет чеки на покупку товаров клиентами

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

• База Каталог, база Клиент
• Рассылка каталогов – позволяет отправить через почту каталоги всем клиентам;
• Отправка товара – позволяет менеджеру осуществить отправку выбранного клиентом товара;
• Ввод заказа - позволяет менеджеру ввести новый заказ;
• Изменение заказа – позволяет менеджеру изменить заказ;
• Заказ через интернет – позволяет клиенту оформить заказ через интернет;
• Вход в систему - предназначен для входа пользователей в программу.

Затем создается диаграмма вариантов использования (Рисунок 2).

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

Далее приведем краткое описание нескольких вариантов использования:

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

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

• Открывается форма заказа
• Менеджер нажимает кнопку "Новый документ"
• При вводе нового заказа система автоматически присваивает ему идентификационный номер документа (IdDoc)
• Менеджер заполняет номер документа, дату операции, наименование клиента
• Если заполнены все вышеперечисленные поля, система позволяет ввести позиции документа. В противном случае система возвращает сообщение об ошибке, что не все поля заполнены, и предлагает вернуться к заполнению шапки документа
• Начинается ввод позиций документа
• При нажатии на кнопку "создать позицию" создаётся новая позиция заказа
• При создании каждой позиции система присваивает идентификационный номер позиции (IdPos)
• Заполняются поля: номенклатура, кол-во и цена
• При необходимости вводятся новые позиции
• После ввода всех позиций заказа менеджер нажимает кнопку "Сохранить"
• Документ сохраняется в БД
• Менеджер нажимает на кнопку "Печать"
• Информация о документе появляется в распечатанном виде.

Альтернативный поток событий – если менеджер не заполняет все поля формы, система не даёт возможность сохранить заказ.

Предусловия - отсутствуют.

Постусловия – если вариант использования выполнен успешно, в БД создаётся новый заказ. В противном случае состояние БД не изменяется.

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

1. Вход в систему – Данный вариант использования описыва­ет вход пользователя в систему обработки заказов.

Основной поток событий – данный вариант использования начинает выполняться, ког­да пользователь желает войти в систему:

• Система запрашивает имя пользователя и пароль.
• Пользователь вводит имя и пароль.
• Система проверяет имя и пароль, после чего открывается.

Альтернативные потоки - Неправильное имя/пароль. Если во время выполнения Основного потока обнаружится, что пользователь ввел неправильное имя и/или пароль, система выводит сообщение об ошибке. Пользователь может вернуться к началу Основного потока или отказаться от входа в систему, при этом выполнение варианта использования завершается.

Предусловия – отсутствуют.

Постусловия – если вариант использования выполнен успешно, пользователь входит в систему. В противном случае состояние системы не изменяется.

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

Рассмотрим более подробно описание диаграммы последовательности для варианта использования «Ввод заказа»

Диаграмма последовательности для варианта использования «Ввод заказа» (Рисунок 3) включает следующие процедуры:

• 1. Open() – позволяет открыть форму заказа.
  2. Create() – позволяет создать новый заказ при нажатии накнопку «Новый заказ».
  3. Order() – позволяет ввести данные заказа.
  4. Save() – позволяет сохранить заказ.
  5. SaveOrder (Integer) – позволяет сохранить текущий заказ в базе данных.
  6. Print() – позволяет при нажатии на кнопку «Печать» послать запрос на составление отчёта.
  7. Report (Integer) – позволяет получить печатный отчёт текущего заказа.

Рисунок 3 – Диаграмма последовательности для варианта использования

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

Рисунок 4 – Кооперативная диаграмма «Ввод заказа»

Рисунок 5 – Кооперативная диаграмма «Отправка товара»

Цели проектирования архитектуры системы:

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

Вводятся глобальные Пакеты:

• базисные (foundation) классы (списки, очереди и т.д.);
• обработчики ошибок (error handling classes);
• математические библиотеки;
• утилиты;
• библиотеки других поставщиков.

Определяются проектные классы (designclasses):

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

Соглашения по проектированию интерфейсов:

• имя интерфейса: короткое (одно-два слова), отражающее его роль в системе;
• описание интерфейса: должно отражать его обязанности;
• описание операций: имя, отражающее результат операции, ключевые алгоритмы, возвращаемое значение, параметры с ти­пами;
• документирование интерфейса: характер использования операций и порядок их выполнения (показывается с помощью диаграмм последовательности), тестовые планы и сценарии и т.д. Вся эта информация объединяется в специальный пакет со сте­реотипом «subsystem», который содержит элементы, образу­ющие подсистему, диаграммы последовательности и/или коопе­ративные диаграммы, описывающие взаимодействие элементов при реализации операций интерфейса, и другие диаграммы;
• класс «subsystemproxy» непосредственно реализует интер­фейс и управляет реализацией его операций;
• все интерфейсы должны быть полностью определены в про­цессе проектирования архитектуры, поскольку они будут служить в качестве точек синхронизации при параллельной разработке.

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

Рисунок 6 – Классы

• граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо - вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации);
• классы - сущности (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов - сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования;
• управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

Рисунок 7 – Структура логического представления браузера

Затем строится диаграмма классов (Рисунок 8, 9).

Рисунок 8 – Диаграмма классов «Ввод заказа»

Рисунок 9 – Диаграмма классов «Отправка товара»

Проектирование баз данных выполняется с помощью средства DataModeler. Его работа основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы «сущность-связь» и последующая генерация описания БД на SQL.В данной курсовой работе были спроектированы следующие таблицы (Рисунок 10):

Рисунок 10 – Таблицы

• 1. Шапка документа со следующими атрибутами:
• IdDoc – идентификатор документа (первичный ключ)
• Customer – клиент
• DateOper – дата документа
• NumDoc – номер документа
  1. Позиции документа со следующими атрибутами:
• IdPos – идентификатор позиции (первичный ключ)
• Goods – номенклатура
• Quantity – количество
• Price – цена
• IdDoc – ссылка на идентификатор документа (внешний ключ).

ЗАКЛЮЧЕНИЕ

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

СПИСОК ЛИТЕРАТУРЫ

1. Бабич А.В. UML. Первое знакомство. Пособие для подготовки к сдаче теста UMO-100 (OMG Certified UML ProfessionalFundamental) (+ CD-ROM) / А.В. Бабич. - М.: Бином. Лаборатория знаний, 2008. - 176 c.

2. Боггс М. UML и RationalRose / М. Боггс. - Москва: РГГУ, 2010. - 385 c.

3. Бородакий Ю.В. Эволюция информационных систем / Ю.В. Бородакий, Ю.Г. Лободинский. - Москва: СИНТЕГ, 2011. - 368 c.

4. Буч, Гради Введение в UML от создателей языка / Гради Буч , Джеймс Рамбо , Ивар Якобсон. - М.: ДМК Пресс, 2015. - 496 c.

5. Буч, Грейди Язык UML. Руководство пользователя / Грейди Буч , Джеймс Рамбо , Айвар Джекобсон. - М.: ДМК, 2015. - 432 c.

6. Гома, Хассан UML. Проектирование систем реального времени, параллельных и распределенных приложений / Хассан Гома. - М.: ДМК Пресс, 2016. - 700 c.

7. Грекул В.И. Управление внедрением информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - Москва: РГГУ, 2014. - 224 c.

8. Гультяев А.К. Проектирование и дизайн пользовательского интерфейса / А.К. Гультяев, В.А. Машин. - М.: Корона-Принт, 2010. - 350 c.

9. Данелян Т.Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c.

10. Зенков В.В. Методы и алгоритмы компьютерной обработки геологической и маркшейдерской информации. Практика обработки заводских данных / В.В. Зенков, О.А. Поляков, В.Е. Юрченко. - М.: Ленанд, 2013. - 268 c.

11. Йордон Эдвард Объектно - ориентированный анализ и проектирование систем / Эдвард Йордон , Карл Аргила. - М.: ЛОРИ, 2014. - 264 c.

12. Карпов Ю.Г. Model Checking. Верификация параллельных и распределенных программных систем (+ CD-ROM) / Ю.Г. Карпов. - М.: БХВ-Петербург, 2010. - 552 c.

13. Киммел Пол UML. Основы визуального анализа и проектирования / Пол Киммел. - М.: НТ Пресс, 2008. - 272 c.

14. Коберн Алистер Современные методы описания функциональных требований к системам / АлистерКоберн. - Москва: Машиностроение, 2012. - 264 c.

15. Ларман Крэг Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку / КрэгЛарман. - М.: Вильямс, 2013. - 736 c.

16. Лоусон Гарольд Путешествие по системному ландшафту: моногр. / Гарольд Лоусон. - М.: ДМК Пресс, 2016. - 368 c.

17. Льюис Ф. Теоретические основы проектирования компиляторов / Ф. Льюис, Д. Розенкранц, Р. Стирнз. - М.: Мир, 2004. - 656 c.

18. Модели глобальной атмосферы и Мирового океана. Алгоритмы и суперкомпьютерные технологии. - Москва: Машиностроение, 2013. - 144 c.

19. Мюллер Роберт Дж. Проектирование баз данных и UML / Мюллер Роберт Дж.. - М.: ЛОРИ, 2013. - 422 c.

20. Пайлон Д. UML 2 для программистов / Д. Пайлон. - М.: Питер, 2012. - 198 c.

21. Приемы объектно - ориентированного проектирования. Паттерны проектирования / Э. Гамма и др. - Москва: СИНТЕГ, 2016. - 366 c.

22. Роберт А. Максимчук UML для простых смертных / Роберт А. Максимчук, Эрик Дж. Нейбург. - Москва: СИНТЕГ, 2014. - 272 c.

23. Фаулер Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. - Москва: СИНТЕГ, 2011. - 192 c.

24. Фельдман Я.А. Создаем информационные системы (+ CD-ROM) / Я.А. Фельдман. - М.: Солон-Пресс, 2007. - 120 c.

25. Шилин К.Ю. Макропроектирование компьютерных обучающих систем / К.Ю. Шилин. - М.: Издательский дом "Дело" РАНХиГС, 2013. - 184 c.