Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Язык моделирования UML).pdf

ArgoUML – инструмент ориентированный на использование с java,тут можно видеть, какие плагины доступны для eclipse, импортировать сгенерированый код. Создавать программные заглушки и др.

Рисунок 2.2 ‑ ArgoUML

Рисунок 2.3 ‑ DIA

DIA ‑ это отличный бесплатный инструмент с открытым исходным кодом UML с простым пользовательским интерфейсомСреда предоставляет возможности:

быстро нарисовать диаграммы UML,

создавать последовательности и диаграммы деятельности,

экспорт диаграмм в eps, pdf, jpg, svg и буфер обмена,

совместно использовать диаграммы с использованием Eclipse,

создавать новые, пользовательские элементы UML.

DIA может генерировать код в Java, PHP, C ++ и многие другие, достаточно установить Dia2code для генерации кода. Может использоваться для создания UML, а затем генерации кода классов.

Cacoo – по сути, векторный редактор (на подобии Visio). Программа бесплатна. Позволяет не только рисовать uml, но и много разных графических объектов (например, топография сети, общий материал и т.д.). В данном случае речь идет именно о рисовании диаграмм, создание полноценных моделей среда не поддерживает.

Рисунок 2.4 ‑ Cacoo

Папирус ‑ набор, разработанный комиссариатом Énergie Atomique во Франции, который сегодня доступен как плагин для Eclipse. Это самый продвинутый инструмент моделирования с открытым исходным кодом и поддержкой UML2. Папирус нацелен на создание интегрированной и удобной для пользователя среды для редактирования любой модели EMF и, в частности, поддержки UML и связанных языков моделирования, таких как SysML и MARTE. Папирус предоставляет диаграммные редакторы для языков моделирования на основе EMF среди них UML 2 и SysML. Papyrus поддерживает Model-Driven Development (MDD), являясь довольно способным инструментом для разработки доменных языков. В связи с этим Papyrus, по-видимому, является единственным инструментом с открытым исходным кодом, поддерживающим шаблон моделированной модели (MDA), выпущенный OMG.

Рисунок 2.5 ‑ Papyrus

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

РАЗДЕЛ 3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ С ПОМОЩЬЮ ОБЪЕКТНО- ОРИЕНТИРОВАННОГО ПОДХОДА (UML-ДИАГРАММЫ)

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

3.1 Постановка задачи

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

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

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

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

• Добавление поставщика

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

• Получение товара

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

• Продажа товара заказчику

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

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

Работа над моделью UML в среде IBM Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования, которая отражает функциональное назначение проектируемой программной системы. Обычно эта диаграмма не детализирует систему, а только описывает основной возможный функционал – показывая доступные способы действий в системе. Как некая степень детализации, возможен показ на диаграмме подсистем, которые задействуются в ходе обращения к основным функциям.

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

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

Построение нашей модели мы тоже начнем с диаграммы вариантов использования.

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

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

Описание прецедентов представим в следующей таблице, она детализирует действия на уровне розничной продажи.

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

Таблица 3.1 ‑ Характеристики прецедентов системы

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

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

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

Модель классов представлена на следующем рисунке (рис 3.2).

Класс «Накладная» описывает объект «Накладная», имеет атрибуты:

- Список товаров – перечень товаров заказа;

- Сумма к оплате – общая цена заказа (сумма цен товаров заказа);

- Тип ‑ «расходная» для клиента, «приходная» для поставщика;

- Номер – для фиксации операции в системе.

«Накладная» предназначена для документирования операций в ходе торговых отношений.

Класс «Товар» описывает объект «Товар», имеет атрибуты:

- Название товара;

- Цена за единицу (порцию);

- Срок годности;

Предназначение полей однозначно трактуется по их названиям.

Класс «Заказ» описывает объект «Заказ», имеет атрибуты:

- Список товаров – перечень товаров заказа;

- Сумма к оплате – общая цена заказа (сумма цен товаров заказа);

- Дата – определяет дату на которую нужно выполнить поставку заказа для клиента;

- Статус – определяет состояние заказа, может принимать значения:

«потенциальный» ‑ желание заказника приобрести товар;

«оформленный» ‑ заказ зарегистрирован в системе;

«отмененный» ‑ клиент отменил заказ;

«оплаченный» ‑ клиент оплатил заказ по накладной;

«выданный» ‑ товары выданы со склада и получены клиентом.

Рисунок 3.2 – Диаграмма классов модели

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

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