CC BY
118
Выводы
В рамках данного исследования JavaFX представляется более эффективной и простой в освоении и применении технологией для разработки графического интерфейса пользователя. Библиотека платформы JavaFX более обширна, нежели набор классов, предоставляемый платформой Qt. Поэтому для реализации приложения на Qt может быть характерно увеличение объёма необходимого кода и дополнительные временные затраты на этапе проектирования. Кроме того, механизм сигналов и слотов, применяемый в Qt, оказался менее гибким и интуитивным, нежели обработка событий, доступная при реализации программы на платформе JavaFX.
Литература
1. Cognitive Dimensions of Notations Resource site [Электронный ресурс]. - Режим доступа: http://www.cl.cam.ac.uk/%7Eafb21/CognitiveDimensions/ - Дата доступа: 3.04.2015.
2. A Notational Usability Benchmark for GUI Programming [Электронный ресурс]. - Режим доступа: https://github.com/eugenkiss/7guis/wiki/ - Дата доступа: 3.04.2015.
3. Comparison of Object-Oriented and Functional Programming for GUI Development [Электронный
ресурс]: E.Kiss. Leibniz Universitat Hannover Faculty of Electrical Engineering and Computer Science Human-Computer Interaction group, August 2014. - Режим доступа:
http://www.eugenkiss.com/proiects/thesis.pdf- Дата доступа: 3.04.2015.
4. Added Qt5 CPP implementation of Circle Drawer example [Электронный ресурс]. - Режим доступа: https://github.com/eugenkiss/7guis/pull/10 - Дата доступа: 5.04.2015.
5. Qt. Cross-platform application & UI development framework [Электронный ресурс]. - Режим доступа: http://www.qt.io/ - Дата доступа: 13.03.2015.
6. JavaFX Overview (Release 8) [Электронный ресурс]: Oracle. Java Documentation. - Режим доступа: http://docs.oracle.com/iavase/8/iavafX/get-started-tutorial/ifX-overview.htm - Дата доступа: 13.03.2015.
7. M. Fowler. GUI Architectures [Электронный ресурс]: Development of Further Patterns of Enterprise Application Architecture. - Режим доступа: http://martinfowler.com/eaaDev/uiArchs.html - Дата доступа: 15.03.2015.
УДК 004.04
ПРОТОТИПИРОВАНИЕ И РЕАЛИЗАЦИЯ ГРАФИЧЕСКОЙ ФОРМЫ ЗАКАЗА ДЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ РЕСТОРАНОВ БЫСТРОГО ПИТАНИЯ
Николенко Ольга Игоревна, студентка, кафедра «Управление персоналом, инновациями и качеством», Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, главный библиотекарь, Донской государственный технический университет, Институт сферы обслуживания и предпринимательства (филиал) ДГТУ в г.Шахты,
Россия, Шахты, [email protected]
Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, [email protected]
В работах [1-2] авторы подробно представили и описали свой опыт проектирования информационной системы для ресторанов быстрого питания. После изучения имеющихся аналогов, их достоинств и присущие недостатков, было принято решение самостоятельно разработать подобный программный продукт. При этом были выделены следующие критерии оптимальности (КО), которые содержат функциональные особенности будущей реализации. Были выделены следующие требования, определяющие необходимость:
1. Предусмотреть возможность автоматизации с помощью единой системы как небольшого кафе (или одного ресторана), так и целой сети заведений.
68
2. Разработать развитый графический интерфейс с поддержкой сенсорных экранов.
3. Реализовать оперативный многопользовательский учет заказов.
4. Реализовать гибкую архитектуру приложения с возможностью расширения в будущем.
5. Предусмотреть возможность печати различных форм отчетности.
Из представленного выше видно, что развитый графический интерфейс очень важен для ИС подобного класса. Это связано с тем, что информационная система ресторана быстрого питания представляет собой систему массового обслуживания, предназначенную для обработки заявок от клиентов. Как правило, в общественных местах в час пик образуется очередь из клиентов, и поэтому необходимо предпринять ряд мер для её сокращения. Классические информационные системы предполагают наличие на рабочих местах пользователей персональных компьютеров с клавиатурой и мышью. В ресторанах быстрого питания чаще всего используют моноблоки с сенсорными экранами. Именно поэтому программе необходим развитый графический интерфейс с поддержкой сенсорных экранов, что описано в требованиях КО2. При этом разрешение экрана, как правило, составляет 1024 на 768 пикселей, и на нем необходимо оптимально разместить выводимую информацию и элементы графического интерфейса. С целью сокращения затрат на оборудование рабочего места, владельцы покупают относительно слабые моноблоки с процессорами Intel Atom с тактовой частотой 1,66 ГГц. Эти аппаратные средства накладывают ограничения на реализацию и выбор целевого языка программирования. В имеющихся ранее статьях реализация этого КО не была описана потому, что на тот момент отсутствовал требуемый функционал.
В настоящий момент модель предметной области построена, т.е. имеется структурная составляющая проекта. Настало время реализовать удобный графический интерфейс, чтобы позволить сотрудникам ресторана эффективно выполнять свои должностные обязанности. Для этого необходимо разработать состав и структуру основной формы приложения и определить эргономичное расположение элементов управления. При этом необходимо определить привязку каждого контрола к соответствующему атрибуту класса который может быть как атомарного типа (число, строка), так и представлять коллекции объектов (например, строки заказа).
В данной статье выполнено прототипирование одной формы графического интерфейса приложения. При этом авторы предложили собственную нотацию, которая позволяет описать привязку классов к графическим элементам интерфейса. Из анализа бизнеспроцессов стало ясно, что ключевой является форма заказа. Именно эта форма, её состав и структура подробно рассмотрены в данной работе. При этом уделено внимание привязке графических элементов к классам и атрибутам/методам классов.
В работах [1-2] была описана одна из первых версий UML-диаграммы классов информационной системы для ресторанов быстрого питания. На рис. 1 представлен фрагмент с уже модифицированной диаграммой, содержащей важные для дальнейшего обсуждения элементы.
Для реализации приложения используется подход, основанный на архитектуре, управляемой моделью (MDA), в основе которой лежит унифицированная метамодель объектной системы, представленная в работах [3-6], где заинтересованный читатель может найти информацию про неё. Для реализации использовалась собственная среда разработки SharpArchitect RAD Studio.
Процесс разработки довольно прост и заключается в последовательном заполнении графических форм, в которых описываются сущности предметной области и атрибуты. Затем организуются отношения ассоциаций и наследования.
69
у WorkStantion *1
Interface
-frNamedObject
ч )
A CreatedWorkStanticn
A CashStant/on
Menu V
Interface
^IBaseRunTimeTreeNodeDomainClass
A Menu
у CashChange *1
Interface
■+ Document
l )
A CashChange
User
Class
■+ SecuritySystemUser
A Garcon A Cashier
Discount
Interface
^NamedOb)ect
InputPaymentParameter
Class
-+ BaseRunTimeMethodParameterClass
E Properties
A A A A A
DepositSumma
OrderSumma
PaymentKind
PaymentSumma
Summa
InputPaymentSumma
Class
■+ BaseRunTimeHelperClass
E Properties A 5umma
InputPaymentSummes ^------------------
Order ft )
Interface
^Document
В Properties
A CurrentPaymentSumma
A 1 s i
f DoAutoPrintln voice
A DoPayment
A InputedPayment
A In voiceCaption
f L eftPayment
A Marne
A Remo ve YoNextCashChange
A Renting
A SummaDiscount
A Summa WithDiscount
A SummaWithoutDiscount
0 Methods
©
© CiearOrderSummaWithDisoount
-■© CreatePayment
© DoPaymentKindCash
© DoPaymentfGndNocash
© DoPaymentfdndWithoutPayment
© DoPaymentStart
© ExactAmount
© Remo vein voire
J
A 5edhnc?j
Settings ^
Interface
■►iBaseRunTimeDomainClass
“►iBaseRunTimeSingletonDomainClass
А
Table *1
Interface
^NamedObject
l )
A PianUnit
A ActuaiOrderltems
A Orderltems
A d?rofei-
A Payments
OrderStatus ft
Enum
None
Printed
Payed
A InputPaymentSummes A PaymentKind
PaymentKind ft
Enum
Cash
Noncash
WithoutPayment
Payment
Interface
IBaseRunTimeDomainClass
В Properties A Contractor A Ocfer A Summa
A Paymentfdnd
Orderltem ft>
Interface
^ IBaseRunTimeDomainClass
0 Properties
A AiiModifiers
A Count
f> DateCreated
A DefeteReason
A Menu
A PercentDiscount
A PianCount
A Price WithDiscount
A Price WithoutDiscount
A Summa WithDiscount
A SummaWithoutDiscount
A Unit
0 Methods
© ChangeCount
© ChangePianCount — — —.
© CiearModfiers
© DecreaseCount
© IncreaseCount
© SetModifiers
)
Unit
Interface
^NamedObject
ChangeCountParameter ft
Class
■+ BaseRcinTimeMethodParameterClass
Э Properties A Count
ChangePlanCountParameter
Class
^ChangeCountParameter
\ t A Modifiers
A_________________
Modifier
Interface
^ IBaseRunTimeTreeNodeDomainClass
Рис. 1 - Фрагмент модифицированной UML-диаграммы классов информационной системы для
ресторанов быстрого питания
Т.е. при проектировании программной составляющей ИС прежде всего анализируются типы сущностей прикладной предметной области. Отметим, что в данном случае нами использованы четыре типа сущностей:
1. Сохраняемые. Они используются для преставления информации, которая физически хранится в базе данных. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса DomainClass метамодели. При этом для реализации выполняется формирование интерфейсов языка C# (см. рис. 1 Interface).
2. Вспомогательные. Экземпляры этих сущностей не сохраняются в БД, но их представление в системе необходимо для упрощения как реализации бизнес-логики, так и для отображения вспомогательной информации в интерфейсе пользователя. Описание подобных сущностей выполняется с помощью создания экземпляров метакласса HelperClass метамодели. При этом для реализации объявляются классы языка C# (см. рис. 1 Class, связанные отношением ассоциации с использующими интерфейсами).
3. Классы-параметры методов. Основная бизнес-логика приложения реализуется в виде методов классов. Этот подход соответствует объектно-ориентированной парадигме. При этом в конечном итоге методы представляются пользователю в виде элементов графического интерфейса, например, в виде кнопок. При этом методы могут принимать набор параметров. В SharpArchitect RAD Studio применяется паттерн проектирования параметр-объект (Parameter Object), предполагающий передачу одного экземпляра классов в виде параметра в метод класса вместо множества атомарных переменных. Описание подобных сущностей осуществляется с помощью создания экземпляров метакласса MethodParameterClass метамодели. При этом для
70
реализации выполняется генерация классов языка C# (см. рис. 1 Class, связанные отношением зависимости с использующими методами).
4. Классы-перечисления/множества. Эти классы используются в том случае, когда атрибут может принимать определенное значение из описанного ранее набора и этот набор не может расширяться пользователями. Для реализации выполняется генерация перечислений языка C# (см. рис. 1 Enum).
При дальнейшем обсуждении будем все реализации различных сущностей называть классами, не выделяя различий между сгенерированными интерфейсами и классами, которые физически генерируются на языке C#. Ключевыми классами предметной области являются Order и OrderItem, используемые для представления заказов и строк заказов (купленных товаров) соответственно. Общие настройки программы, которые используются повсеместно в программе представляются классом Settings, реализующий шаблон проектирования Singleton. Иерархическое меню, реализующее древовидную структуру, описанную в виде класса Menu. Для каждого заказа указывается две рабочих станции (компьютера): 1) Создавшая заказ; 2) Станция кассира, принимающего оплату. Для указания обслуживаемого стола используется класс Table. Работа во многих ресторанах организована посменно, что реализовано в виде класса CashChange.
Перед входом в систему сотрудник ресторана, который является с точки зрения программы пользователем, должен авторизоваться, что соответствует КО3 из [1-2]. Поэтому был выделен класс User, позволяющий сохранить информацию о кассире и официанте, обслуживающем заказ. Постоянным клиентам могут быть предоставлены скидки, что описывается с помощью класса Discount. Для представления платежей по заказу используется класс Payment о различных типах платежей (наличный, безналичный расчёт), описываются перечисления PaymentKind.
С помощью отношений зависимости на представленной UML-диаграмме классов показывают связь между методом класса предметной области и классом-параметром метода. Экземпляр класса InputPaymentParameter используется в методе CreatePayment, который позволяет создать оплату заказа. Вспомогательный класс InputPaymentSumma будет использован для упрощения процесса оплаты заказа по частям, т.е. в том случае, когда часть суммы оплачена наличными, а часть - безналичным расчётом.
Для указания различных модификаторов заказа, например, опции «Без лука» используется класс Modifier. Сами модификаторы прописываются в методе SetModifiers класса Orderltem. Количество товара указывается в методе ChangeCount и использует параметр типа ChangeCountParameter. Для указания планового количество весового товара, например, шашлыка используется метод ChangePlanCount и класс ChangePlanCountParameter.
Перейдем к рассмотрению прототипа графической формы заказа, представленного на рисунке 2. Рассмотрим представленный прототип более подробно. Сначала опишем разработанную авторами нотацию, позволяющую выполнять прототипирование интерфейса для подобного типа приложений, для которых корректное и эргономичное представление информации является необходимым условием эксплуатации приложения. Для ссылки на используемые элементы диаграммы классов, изображённой на рисунке 1, используются угловые скобки “<...>”. Для представления методов классов, преобразованных в графические элементы (в нашем случае в кнопку), в конце записи используются круглые скобки “()”. Для действий, которые оперируют другими графическими элементами, используется префикс “ac”, при этом в угловых скобках “<...>” указывается класс или свойство, на которые направлено действие.
В верхней части формы находится общая информация по заказу, а именно: номер обслуживаемого стола и ФИО официанта. Кроме того, в правом верхнем углу находится кнопка, позволяющая закрыть форму.
71
Рис. 2 - Прототип графической формы заказа
С конструктивной точки зрения, представленная графическая форма заказа состоит из двух частей. В левой верхней части находится список заказанных товаров, а в нижней левой - сводная информация по заказу и элементы управления. Правая часть формы содержит в верхней части набор кнопок, манипулирующих отдельной строкой заказа, а нижняя часть позволяет выбрать новый товар и добавить его в качестве строки. Заголовки кнопок позволяют понять их назначение, и поэтому не имеет смысла их описывать подробно.
В статье представлен прототип основной формы разрабатываемого приложения, которая позволяет отобразить заказ и его содержимое на сенсорном экране. В настоящий момент с сотрудниками ресторана обсуждается расположение графических элементов. С помощью разработанной авторами нотации, показана привязка отдельных кнопок и полей редактирования к атрибутам классов. Это позволит упростить процесс реализации формы за счет того, что уже на этапе прототипирования уделяется этому внимание. Дальнейшим развитием описанной статьи является фактическая реализация описанной формы, а также проектирование и реализация формы оплаты заказа, реализация механизмов печати отчетных форм и чеков. Предполагается выполнять прототипирование с помощью описанной нотации.
Литература
1. Олейник П.П., Юзефова С.Ю., Николенко О.И. Опыт проектирования информационной системы для ресторанов быстрого питания // Объектные системы - 2014 (Зимняя сессия): материалы IX Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. С. 12-16.
2. Oleynik P.P., Yuzefova S.Yu., Nikolenko O.I. Designing and implementation an information system for fast food restaurants. Modern informatization problems in economics and safety: Proceedings of the XX-th International Open Science Conference (Yelm, WA, USA, January 2015)/ Editor in Chief Dr. Sci., Prof. O.Ja. Kravets. - Yelm, WA, USA: Science Book Publishing House, 2015. pp. 112117.
3. Oleynik P.P. Domain-driven design the database structure in terms of metamodel of object system. Proceedings of 11th IEEE East-West Design & Test Symposium (EWDTS'2013), Institute of Electrical and Electronics Engineers (IEEE), Rostov-on-Don, Russia, September 27 - 30, 2013, pp. 469-472.
72
4. Олейник П.П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. №4(26). - С. 69-76.
5. Олейник П.П. Предметно-ориентированное проектирование структуры базы данных в понятиях метамодели объектной системы // Объектные системы - 2014: материалы VIII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. - С. 41-46.
6. Oleynik P.P. Using metamodel of object system for domain-driven design the database structure. Proceedings of 12th IEEE East-West Design & Test Symposium (EWDTS’2014), Kiev, Ukraine, September 26 - 29, 2014, DOI: 10.1109/EWDTS.2014.7027052
УДК 004.04
UML-ПРОФИЛЬ ПРОЕКТИРОВАНИЯ СТРУКТУРЫ ОБЪЕКТНООРИЕНТИРОВАННОЙ БАЗЫ ДАННЫХ11
Гурьянов Василий Иванович, к.т.н, доцент, Филиал Санкт-Петербургского государственного экономического университета в г.Чебоксары, Россия, Чебоксары, [email protected] Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, [email protected]
В настоящее время большинство нового программного обеспечения информационных системы разрабатывается с применением объектно-ориентированного подхода, что обусловлено наличием множества достоинств. Все чаще этот подход применяется не только для клиентского приложения, но и для реализации структуры БД (при использовании ОРСУБД и ООСУБД). Именно поэтому возникает потребность в применении методик и подходов, позволяющих упростить процесс проектирования ООБД, что является ключевой задачей данной работы.
Идея данной статьи не нова. Так в работах [1-3] один из авторов предложил свое решение описанной проблемы, основанной на построении диаграммы объектов, элементами которой являются экземпляры классов метамодели, представленной в [4-5]. На первый взгляд рабочее решение оказалось совершенно не пригодным при проектировании больших информационных систем, автоматизирующих прикладные предметные области реального мира. Это связано с громоздкостью полученных диаграмм объектов, содержащих большое количество экземпляров и связей между ними. Описанное в тех работах решение не удалось применить при обучении студентов проектированию объектно-ориентированных приложений. Это связано с тем, что обучающиеся вынуждены изучать синтаксис двух UML-диаграмм (диаграмм классов и диаграмм объектов), а это требует дополнительного времени и увеличивает время выполнения лабораторных работ.
С целью исключения описанных недостатков предыдущих работ появилась необходимость в поиске альтернативного подхода. Такое решение в настоящий момент авторы видят в разработке собственного UML-профиля, что позволит упростить процесс проектирования программных продуктов. Этот подход успешно и многократно применялся первым автором данной статьи, что описано в работах [6-8]. Именно тонкостям разработки собственного UML-профиля, который оперирует сущностями метамодели объектной системы, и посвящена данная статья.
Для демонстрации полученного решения будем использовать тестовую объектную статическую модель, описанную в [9] и представленную на рис. 1.
11 Статья рекомендована к опубликованию в журнале "Информационные технологии"
73
