Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (Структура и основные понятия объектно-ориентированного).pdf

1.3. Структура и основные понятия объектно-ориентированного проектирования экономических информационных систем

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

Общая структура UML представлена на рисунке 10 [12–14].

Рисунок 10 – Структура UML

Семантика – раздел лингвистики, изучающий значение языковых единиц: слов и словосочетаний [22].

Синтаксис – способы построения словосочетаний, предложений из отдельных слов [22].

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

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

В UML представлено 3 типа сущностей:

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

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

Таблица 2 - Отношения

Название	Обозначение	Семантика
Ассоциация		Отношение, определяющее существенную связь между двумя и более сущностями.
Агрегация		Подкласс ассоциации, определяющий связь «часть»–«целое» (ромб), в котором они могут существовать отдельно друг от друга. Отношение может существовать только между сущностями одного и того же типа.
Композиция		Подкласс агрегации, в которой «части» и «целое» не могут существовать отдельно друг от друга.
Зависимость		Отношение между двумя сущностями, в котором изменение в одной из них (независимой – указывается со стороны стрелки) может влиять на поведение или состояние – зависимой.
Обобщение		Отношение между обобщенной сущностью (родитель – отмечается треугольником) и конкретизированной сущностью (потомком). Отношение может существовать только между сущностями одного типа
Реализация		Отношение между сущностями, когда одна из них определяет действие (указывается со стороны стрелки), которое другая должна выполнить. Отношения используются в следующих случаях: между вариантами использования и кооперациями, между интерфейсами и классами.

---

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

• любое число экземпляров, в т.ч. и нулевое значение;
• любое неотрицательное целое число, кратность которого строго фиксирована;
• диапазон неотрицательных целых чисел, например (0..3);
• диапазон чисел с «открытым» конечным значением (неменьше заданного значения), например (3..*);
• перечисление целых неотрицательных значений или/и диапазонов через запятую, например: 0, 2..4.

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

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

Таблица 3 - Механизмы расширения

Название	Обозначение	Семантика
Стереотип	« »	Уточняет семантику элемента.
Сторожевое условие	[  ]	Логическое условие.
Ограничение	{  }	Ограничивает семантику элемента модели.
Помеченное значение	{  }	Новое или уточняющее свойство элемента.

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

Рисунок 11 – Примеры стандартного и стереотипного отображения класса, слева на право: стандартное обозначение, стандартное обозначение с текстовым стереотипом, графический стереотип.

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

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

---

Таблица 4 - Связь моделей и диаграмм

Модель	Диаграмма
	Вариантов использования	Состояний	Классов	Кооперации	Последовательности	Деятельности	Компонентов	Развертывания
Вариантов использования	+	+	+	+	+
Анализа	+	+	+	+	+
Проектирования		+	+	+	+	+
Реализации			+				+	+

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

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

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

2. Проектирование экономической информационной системы на примере

---

2.1. Обзор объекта

Рассмотрим использование UML для проектирования автоматизированной системы на примере магазина косметики.

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

1. Менеджер отдела продаж каждый день оформляет заявки клиентов на покупку косметики согласно прайс-листу. Он регистрирует заявки в журнале заявок.

2. После оформления заявки менеджер отдела продаж выписывает счёт клиенту и регистрирует его в реестре счетов.

3. Бухгалтер получает и обрабатывает приходные кассовые ордера, а также выписки банка, которые содержат сведения о поступлении денежных средств в кассу или на расчётный счёт магазина. На основании этих документов бухгалтер делает отметки об оплате счета в реестре счетов.

4. Менеджер отдела продаж контролирует поступление платежей от клиентов. Если срок оплаты истёк, а платежи не поступили, то менеджер отмечает недействительность заявки в журнале заявок.

5 Менеджер отправляет счёта о покупке продавцу-консультанту.

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

7. В конце каждого месяца на основании журнала заявок менеджером отдела продаж формируется сводка о количестве поступивших заявок на каждое наименование косметики. На рисунках 12-15 представлены основные модели данного бизнес-процесса.

Рисунок 12 – Диаграмма действий бизнес-процесса «Продажа косметики»

Рисунок 13 – Контекстная диаграмма модели IDEF0 бизнес-процесса «Продажа косметики».

Рисунок 14 – Диаграмма декомпозиции первого уровня детализации контекстной диаграммы

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

Произведем моделирование информационной системы по продаже косметики через интернет.

---

2.2 Объектно-ориентированное проектирование системы с использованием языка UML

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

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

Сценарии выполнения основных прецедентов представлены в таблицах 5-10.

Таблица 5 – Сценарий выполнения прецедента «Учет заказов»

Прецедент	Учет заказов
Актеры	Покупатель, информационная система
Цель	Регистрация и направление заказа на доставку
Краткое описание	Покупатель регистрируется в системе, выбирает товар, оформляет заказ, возможно получает скидку, оплачивает, информационная система регистрирует заказ и составляет счет-фактуру заказа, направляет ее в магазин, для последующей продажи
Тип	Базовый
Ссылки	«Оформление заказа», «передача заказа в магазин»

Таблица 6 – Типичный ход события «Учет заказа клиента»

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

Таблица 7 – Сценарий выполнения прецедента «Оформление заказа»

Прецедент	Оформление заказа
Актеры	Покупатель
Цель	Составление заказа и оплата стоимости заказа
Краткое описание	Покупатель набирает товар, оформляет заказ, возможно ему предоставляется скидка, далее он оплачивает стоимость товара
Тип	Включающий
Ссылки	«регистрация покупателя», «формирование заказа», «оплата товара», «скидка»

---