CC BY
202
При этом классы Product и Service унаследованы от двух базовых абстрактных классов (Commodity и IBaseRunTimeTreeNodeDomainClass). Корневой
IBaseRunTimeTreeNodeDomainClass - это встроенный системный класс, предоставляемый средой разработки и позволяющий организовать иерархию экземпляров определенных классов. Древовидные структуры очень удобны для группирования услуг и товаров в категории. При этом уровень иерархии описываемых классов не имеет ограничений на глубину. Текущая реализация не позволит смешивать различные узлы в единой иерархии. Т.е. невозможно смешивать услуги и товары в одном дереве. Этого сложно было бы достичь при одиночном наследовании (при наследовании Commodity от IBaseRunTimeTreeNodeDomainClass). Эти базовые классы на диаграмме явно не показаны, но присутствуют в обозначении класса в виде Additional Parents секции.
Базовый класс Commodity является абстрактным и представляет объект потребления. Его введение в иерархию обусловлено необходимостью организации ассоциации с OrderRow, который представляет собой строку заявки и содержит ссылку на товар или на услугу.
Несмотря на наличие ряда ключевых достоинств, позволяющих адекватно представить реалии мира в виде программного обеспечения с помощью множественного наследования, у него имеется ряд недостатков [3]. Чаще всего отмечают совпадение имен переменных и методов у предков класса и неоднозначности пути наследования в случае, более чем двухуровневой иерархии. Для решения проблемы экземпляр класса необходимо привести к требуемому базовому классу. Отметим, что все перечисленные в различных источниках недостатки не наносят существенного ущерба, зато дают ряд преимуществ, описанных ранее. Эти преимущества позволяют избежать ошибок ввода информации и провести первичную валидацию, что особенно актуально в крупных информационных системах.
Литература
1. Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М. : Издательский дом "Вильямс", 2003. - 1440 с. : ил. - Парал. тит. англ.
2. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.: ил. + цв. Вклейки (+ 2 DVD).
3. Труб Илья. О проблемах множественного наследования, http://www.osp.ru/os/2001/02/179920/
УДК 004.04
ОПЫТ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ РЕСТОРАНОВ
БЫСТРОГО ПИТАНИЯ
Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, xsl@list.ru Юзефова Светлана Юрьевна, студентка, кафедра «Управление персоналом, инновациями и качеством», Шахтинский институт (филиал) Южно-Российского государственного политехнического
университета им. М.И. Платова, Россия, г.Шахты Николенко Ольга Игоревна, студентка, кафедра «Управление персоналом, инновациями и качеством», Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, старший библиотекарь, Донской государственный технический университет, Институт сферы обслуживания и предпринимательства (филиал) ДГТУ в г.Шахты,
Россия, г. Шахты, 13smile2009@rambler.ru
Посещение ресторанов быстрого питания стало неотъемлемым элементом в жизни
12
современного человека. Это привело к повсеместному появлению подобных заведений, и как следствие, перед руководителями возникает задача автоматизации деятельности, выбор и внедрение информационной системы. От успешного решения этой задачи зависит успех всего бизнеса. Как правило, существуют два основных решения. Первое предполагает выбор и внедрение существующей системы. Второе решение предполагает самостоятельную разработку программного продукта для нужд организации.
Именно опыту проектирования и реализации информационной системы для ресторанов быстрого питания посвящена данная статья. В работе представлена UML-диаграмма, содержащая все выделенные классы и позволяющая продемонстрировать разработанный функционал.
Наиболее популярной информационной системой, автоматизирующей деятельность ресторанов в России, является система iiko [1]. Наличие множества внедрений позволяет утверждать, что описываемая система является стандартом, именно по её функционалу и нужно равняться. Перед собственной реализацией необходимо выделить критерии оптимальности (КО), которые содержат функциональные особенности будущей реализации. Были выделены следующие требования, определяющие необходимость:
1. Предусмотреть возможность автоматизации с помощью единой системы как небольшого кафе (или одного ресторана), так и целой сети заведений.
2. Разработать развитый графический интерфейс с поддержкой сенсорных экранов.
3. Реализовать оперативный многопользовательский учет заказов.
4. Реализовать гибкую архитектуру приложения с возможностью расширения в будущем.
5. Предусмотреть возможность печати различных форм отчетности.
Рассмотрим каждый критерий более подробно. Требования КО1 предполагают использование единой ИС независимо от масштабов организации: от одиночного ресторана до крупной сети. Часто подобные требования называют масштабируемостью системы. Ключевым достоинством в свете рассматриваемой задачи является снижение затрат на обучение персонала (официантов, кассиров, менеджеров, управляющих) и в конечном итоге повышения прибыли от деятельности.
Информационная система ресторана быстрого питания представляет собой систему массового обслуживания, предназначенную для обработки заявок от клиентов. Как правило, в людных местах в час пик образуется очередь из клиентов, и поэтому необходимо предпринять ряд мер для ее сокращения. Классические информационные системы предполагают наличие на рабочих местах пользователей персональных компьютеров с клавиатурой и мышью. В ресторанах быстрого питания чаще всего используют моноблоки с сенсорными экранами. Именно поэтому программе необходим развитый графический интерфейс с поддержкой сенсорных экранов, что описано в требованиях КО2. При этом разрешение экрана, как правило, составляет 1024 на 768 пикселей и на нем необходимо оптимально разместить выводимую информацию и элементы графического интерфейса. С целью сокращения затрат на оборудование рабочего места, владельцы покупают относительно слабые моноблоки с процессорами Intel Atom с тактовой частотой 1,66 ГГц. Эти аппаратные средства накладывают ограничения на реализацию и выбор целевого языка программирования.
Бизнес-процесс ресторана соответствует системе массового обслуживания и в упрощенном виде предполагает наличие одного компьютера с установленной программой, доступ к которой имеют множество пользователей различных категорий: официанты, менеджеры, товароведы. Доступ осуществляется по уникальному коду, прописанному в прокси-карте. Т.е. каждый пользователь, подходя к компьютеру, подносит прокси-карту к считывающему элементу и, авторизовавшись в системе, выполняет требуемые действия. Затем он выходит из системы и подходит следующий пользователь. Скорость обслуживания
13
во многом зависит от скорости входа в систему. Т.е. требуется реализовать оперативный многопользовательский учет заказов, что записано выше как КО3. При этом различным группам пользователей необходимо предоставить различный интерфейс, оптимальный для выполнения должностных обязанностей. Например, официанту необходимо вносить и редактировать заказы. Менеджеру необходимо лишь просматривать и иметь возможность удалять заказы. При этом необходимо предусмотреть возможность выполнения различных операций под определенной ролью пользователя. Например, официант для предоставления скидки должен пригласить менеджера и только последний может выбрать скидку и подтвердить ее. Товароведу необходим стандартный интерфейс пользователя, позволяющий вносить новые товарные позиции, организовывать их в иерархии, что проще всего реализовать с помощью таких элементов управления, как выпадающие списки.
КО4 требует реализовать гибкую архитектуру приложения с возможностью расширения в будущем. Прогресс не стоит на месте, постоянно появляются новые устройства и технологии. Поэтому разработка гибкой архитектуры позволит сохранить инвестиции в будущем, когда потребуются серьезные доработки системы. В настоящее время для разработки новых программных продуктов используются чаще всего объектноориентированные языки программирования, основными свойствами которых является инкапсуляция, полиморфизм, наследование. Для сохранения информации в долговременной памяти используется БД, под управлением СУБД. В настоящее время наиболее популярными являются реляционные СУБД. Из-за наличия существенных различий в организации и обработке данных в объектно-ориентированных языках программирования и в реляционных системах управления данными возникает объектно-реляционное несоответствие, для преодоления последствий которого используют методы (шаблоны, паттерны) объектнореляционного отображения. Популярные подходы решения описанной проблемы подробно представлены в работах [2-3]. Таким образом, для соответствия КО4 одним из решений является разработка клиентского приложения на ОО-языке программирования, а в качестве хранилища информации необходимо выбрать реляционную СУБД.
Печатные формы отчетности - это один из неотъемлемых элементов современной информационной системы. Особенность в нашем случае в том, что к рабочему месту пользователя ИС подключен только лишь принтер чеков (подключенный по USB или RS-232), использующий для вывода на печать рулон бумаги шириной 8 см. Поэтому все сформированные отчеты должны использовать этот тип бумаги вместо общепринятого формата A4. Ситуация осложняется тем, что помимо непосредственного чека (счета по заказу) необходимо печатать отчет по кассовой смене, содержащий как подробную, так и сводную информацию по всем заказам. Описанное выше позволило сформировать требования КО5.
Перейдем к рассмотрению реализации описываемой системы. Проектирование современных информационных систем, разрабатываемых на ОО-языке программирования, выполняется с помощью построения диаграммы классов унифицированного языка моделирования UML. На рисунке 1 представлена эта диаграмма. Ключевой особенностью ОО-парадигмы является возможность организации иерархии классов с помощью наследования. Рассматриваемая предметная область содержит множество справочников, таких как Столы, Скидки, Контрагенты, Рабочие станции, Места хранения продуктов, Единицы измерения. Все эти сущности содержат только один атрибут Название, поэтому имеет смысл выделить базовый абстрактный класс NamedObject и унаследовать все справочники от него (см. рис. 1). Справочник товаров - это иерархическая структура, разбивающая товар по категориям и подкатегориям.
14
NamedObject
Рис. 1 - UML диаграмма классов информационной системы для ресторанов быстрого питания
15
В программе она реализована в виде дерева и представлена классом Menu, содержащим атрибут Owner для сохранения ссылки на родительский узел и вычисляемый атрибут Nodes, содержащий дочерние от данного узла узлы.
При создании строк заказа, содержащих продукт, клиент может отказаться от какого-либо ингредиента. Для учета этого отказа в программе создан иерархический справочник Modifier.
В системе предусмотрено два вида документов, корневым абстрактным классом для которых выступает класс Document. Первый представляет собой заказ и описывается классом Order. Для описания заказываемых блюд используется набор строк, экземпляр которых описывается классом Orderltem. Второй документ - это CashChange, т.е. кассовая смена.
Рассмотрим соответствие разработанной иерархии выделенным ранее критериям оптимальности. KOi требует предусмотреть возможность автоматизации с помощью единой системы как небольшого кафе (или одного ресторана), так и целой сети заведений. Как видно из рис. 1, отсутствует какая-либо привязка к конкретной организации, т.е. удалось унифицировать систему, что и требовалось сделать.
Требование разработать развитый графический интерфейс с поддержкой сенсорных экранов предусмотрено в КО2. В настоящий момент реализуется именно это требование, т.к. оно является основным для конечных пользователей.
С помощью отдельной структуры групп пользователей и пользователей реализуется оперативный многопользовательский учет заказами. Отметим, что разработанная иерархия ортогональна к этому требованию, поэтому реализовать КО3 не составит особого труда.
В приложении реализована классическая двухзвенная архитектура «клиент-сервер», где в качестве СУБД используется Microsoft SQL Server 2012, а клиентское приложение написано на платформе .Net Framework. Следовательно, система удовлетворяет КО4, т.к. удалось реализовать гибкую архитектуру приложения с возможностью расширения в будущем.
Печатные формы представляют собой по своей сути выборку данных в ходе выполнения многотабличных запросов из РСУБД. После применения методов объектнореляционного отображения был получен набор реляционных таблиц, которые физически представляют классы, представленные на рис. 1. В результате реализованы требования КО5.
Дальнейшим развитием системы является написание различных валидационных правил, позволяющих проверить достоверность информации уже на этапе ввода данных. Т.к. для реализации описанной информационной системы используется собственная среда разработки, представленная в работе [2], то подобные ограничения представляются в виде набора логических выражений, подробное описание которых может стать материалом для следующей статьи.
Литература
1. Автоматизация ресторана iiko, http://iiko.ru/
2. Олейник П.П. Унифицированная модель для тестирования инструментов объектнореляционного отображения // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 65-69.
3. Олейник П.П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. №4(26). - С. 69-76.
16
УДК 04.004
ОПЫТ ВЫПОЛНЕНИЯ РЕИНЖИНИРИНГА ОБЪЕКТНОЙ МОДЕЛИ НА ПРИМЕРЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ КАТАЛОГИЗИРОВАНИЯ НАУЧНЫХ СТАТЕЙ ПРИ ПРОВЕДЕНИИ МЕЖДУНАРОДНЫХ КОНФЕРЕНЦИЙ
Бородина Наталья Евгеньевна, студентка, Ивановский государственный химико-технологический университет, Россия, Иваново, natashka0108@yandex.ru Олейник Павел Петрович, Россия, Ростов-на-Дону, xsl@list.ru Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, portugaled@yandex.ru
Введение
Одним из основных путей обмена научными знаниями, способом демонстрации своих научных достижений является их публикация в научных журналах и представление на научных конференциях. Наиболее доступным, динамичным и эффективным является именно участие в публичных научных конференциях. На сегодняшний день существует огромное количество научных конференций. Перед организаторами таких конференций возникает серьезная проблема эффективного управления подаваемыми на конференцию научными публикациями и большим объемом дополнительных вспомогательных данных организационного характера: данных о рецензии, оплате, отправленных сборниках и т.п. Решение этих задач требует разработки и использования автоматизированных информационных систем.
Идея создания подобных программных продуктов не нова. В каждом ВУЗе она решается по-своему, от применения простых Excel-файлов до использования сложных многоуровневых Web-приложений. Наиболее проработанной реализацией является система управления научной информацией "ИСТИНА — Наука МГУ", подробно описанная в работе [1]. Но, несмотря на наличие ряда достоинств, система, описанная в [1], не может быть использована при проведении собственных конференций, т.к. не предоставляет возможности сохранения вспомогательной информации, необходимой в этом случае. Поэтому ранее была разработана и активно использовалась собственная система, подробно описанная в работах [2-4]. Однако в ходе эксплуатации и расширения имеющегося функционала были найдены значительные архитектурные ошибки, появление которых во многом связаны с функциональными возможностями выбранного языка программирования (среды разработки) и отсутствием достаточного времени для полноценного проектирования. В результате выявленных архитектурных недостатков возникла настоятельная необходимость в серьезной переделке существующей информационной системы каталогизирования научных работ конференции «Объектные системы» (obiectsvstems.ru).
1. Критерии оптимальности разрабатываемой системы
Прежде чем приступить к разработке информационной системы, необходимо определить и четко сформулировать критерии оптимальности, отражающие требования, предъявляемые к функционалу реализуемого приложения. Для данной системы были выдвинуты следующие критерии оптимальности, описывающие необходимость наличия определенного функционала:
1. Реализовать в системе возможность сохранения информации о различных типах изданий, с учетом того, что издание может быть собственное (проводимое самостоятельно) или внешнее (которое проводится сторонней организацией).
2. Обеспечить возможность сохранения информации об авторах статей с указанием ученых степеней, занимаемых должностей в различных организациях.
17
