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

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

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

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

За счет применения различных аспектов 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.

---