Розничная торговля завершает процесс обращения товаров и представляет собой совокупность видов предпринимательской деятельности, связанных с продажей товаров и услуг непосредственно конечным потребителям.
Розничная торговля является товарообменным процессом, который направлен на удовлетворение потребностей людей с помощью свободной продажи товаров и услуг, которые представляют для них определенную ценность.
Определение термину «розничная торговля» дается в части 2 ГК РФ, в которой говорится, что по договору розничной купли-продажи продавец, осуществляющий предпринимательскую деятельность в сфере розничной торговли, передает покупателю товар, предназначенный для личного, семейного, домашнего или иного использования, не связанного с предпринимательской деятельностью, т.е. розничные торговцы реализуют товар конечным потребителям.
В розничной торговле учитываются интересы продавца, связанные с получением доходов, а также потребности покупателя, связанные с получением высококачественных товаров и услуг.
Декомпозиция предметной области (на примере магазина)
Именно в розничной торговле производители максимально учитывают запросы общества. Основу розничной торговли составляет теория индивидуального выбора, которая исходит из принципа приоритета потребителя. Поэтому розничная торговля является социальным выражением качества жизни общества.
Розничная торговля является инструментом, которы й, реализуя произведенную потребительскую стоимость, связывает производство с потреблением и поддерживает равновесие между спросом и предложением. При этом не имеет значения, кто и где осуществляет реализацию товаров и через какие каналы сбыта они доводятся до конечных потребителей.
Актуальность работы заключается в повышении качества выполнения бизнес-процессов с помощью применения информационных технологий.
Объектом исследования является процесс реализации билетов через розничные кассы.
Предметом исследования является автоматизация процесса реализации билетов через розничные кассы.
Целью работы является разработка регламента выполнения процесса реализации билетов через розничные кассы.
Для достижения поставленной цели необходимо решить ряд задач:
- Дать описание предметной области.
- Выбрать средства моделирования бизнес-процессов.
- Осуществить моделирование бизнес-процессов «как есть».
- Описать мероприятия по улучшению бизнес-процессов.
- Осуществить моделирование бизнес-процессов «как должно быть».
Аналитическая часть
Описание предметной области. Постановка задачи
Продажа билетов на концерты и в театры уже давно является выгодным бизнесом, основу которого составляет наценка на уже купленный билет. В советское время схема извлечения прибыли на перепродаже билетов применялась спекулянтами, деятельность которых была основана на выкупе всех билетов в кассах города и последующей перепродаже. Результатом стало то, что среднестатистический человек был вынужден либо покупать билет по цене очень далёкой от номинала, либо же вовсе отказывать себе в удовольствии посещения мероприятия. Причём с каждым днём приближения к проведению мероприятия, цены у перекупщиков росли в геометрической прогрессии, и, безусловно, такая ситуация была невыгодна абсолютно никому.
«Анализ предметной области». Обучение проектированию программных продуктов. Часть 1. Тренинг 3.
Сегодня также можно перед премьерой или одноразовым мероприятием можно столкнуться с перекупщиками. Однако из деятельность перестала быть востребованной с внедрением инструментов продажи билетов он-лайн. Причиной этому стало распространение интернета среди населения, что повлияло на принцип торговли билетами, и в настоящее время предприниматель, который стремится построить свой бизнес на перепродажах, должен внедрять систему продажи билетов не только в своих кассах, но и на собственном сайте.
Существует несколько способов организации розничной продажи билетов:
- Перепродажа билетов. В этом случае предприниматель скупает крупные партии билетов с целью дальнейшей перепродажи по самостоятельно устанавливаемой цене. По сути такой способ является узаконенной спекуляцией. Основным преимуществом такого метода является возможность ведения той ценовой политики, которая покажется предпринимателю наиболее выгодной, даже если из-за этого цены становятся слишком высоки. Но такой способ имеет и свои недостатки. Например, не все театры пойдут на такую сделку и не продадут крупную партию билетов в одни руки. Предприниматель перенимает на себя все риски по реализации билетов, и в случае незаинтересованности публикой предстоящего мероприятия, организатор только выиграет (зал пустой при аншлаге), а вот перекупщик только потеряет средства. Жёсткая конкуренция при этом не позволит взвинчивать цены слишком сильно, и скупка будет производиться только непосредственно за несколько дней до мероприятия.
- Прямое сотрудничество с организаторами мероприятий. Поскольку не все организации имеют развёрнутую сеть касс, для них это становится способом продать ещё больше билетов. В этом случае предприниматель получает комиссионное вознаграждение от реализации билета, которое устанавливается в определённых пределах. То есть искусственно сильно завышать цены не получится. При этом предприниматель будет являться агентом, и в случае неуспешного мероприятия практически ничем не рискует, кроме потери прибыли. Также он получает всю информацию об оставшихся билетах, может предоставлять своим покупателям схему зала (или просто количество свободных мест) и, таким образом, предоставлять уже расширенный сервис. При такой организации бизнеса необходимо иметь отлаженный сайт с возможностью соединения с базой своих партнёров для оперативного получения информации. Оснащённые компьютерами точки продаж сразу демонстрируют клиенту схему зала и дают ему возможность выбрать удобное место. Как только где-то покупается билет, это становится известно и самому предпринимателю, и партнёру-организатору, и другим агентам, то есть вероятность продать один и то же билет сводится к нулю.
- Работа по франшизе является гораздо более простым вариантом организации собственного бизнеса. Работа по франшизе позволяет получить в распоряжение информацию сразу обо всех партнёрах, разрешение на работу с ними от головной фирмы, которая также даст все наработанные схемы и расскажет об особенностях ведения бизнеса. То есть предоставит полную поддержку в начинании и возможность работать под её известным массовому покупателю имени. Недостатками такого способа организации бизнеса являются необходимость заплатить паушальный взнос; отчисление роялти и необходимость обустройства своих точек продаж в соответствии с требованиями корпорации. Однако в настоящее время существует ряд недорогих франшизы, и франчайзеры не завышают свои требования.
- Продажа билетов через интернет с возможностью самостоятельной распечатки билетов организована следующим образом: покупатель приобретает билет через интернет, после этого печатает на принтере или же может обратиться в удобное для него время в указанную им же ближайшую точку за билетом. Распечатанный на принтере билет называется электронным билетом, но для этого некоторые компании в целях безопасности требуют от покупателя предоставление своих личных данных. Это создано для того, чтобы создать уникальный билет, который нельзя будет перепродать кому-то или подделать. И тем более подделать, а потом перепродать. Обычно крупные организаторы имеют уже системы по генерированию электронных билетов, и предпринимателю остаётся только внедрить это программное обеспечение в свою сеть.
Реализация билетов многих партнёров приводит к необходимости внедрения универсального интерфейса и системы управления, а также персонала, который будет поддерживать работоспособность этой инфраструктуры. Крупная развивающаяся билетная касса постоянно совершенствует именно процесс продажи билетов через интернет, потому что сегодня многие люди ездят на мероприятия в другие города, и ехать специально за билетом может быть очень неудобно.
Отдельного упоминания заслуживают организаторы концертов гастролирующих артистов. Порою такими организаторами выступают уже сотрудничающие партнёры, которые, к примеру, предоставляют свободную от собственных выступлений площадку. Тогда они также передадут информацию о мероприятии, выдадут партию билетов, и работа будет вестись всё по тому же принципу.
Иначе, если концерт или шоу организовывает сторонняя и даже иногородняя компания. Возможно, даже на нестандартной площадке, которая арендуется только на один раз (пример тому – аренда площади города, парковки крупного гипермаркета, ночного клуба). В этом случае предприниматель заключает договор с организатором на реализацию билетов, которые нигде больше нельзя купить (если только организатор не стал сотрудничать сразу с несколькими билетными кассами). Обычно стоимость билета на такое мероприятие постепенно повышается по мере приближения к событию, особенно если наблюдается активный выкуп билетов. Таким образом, предприниматель постоянно повышает свой доход, ведь незначительное постепенное увеличение цены приводит к итоговой стоимости значительно выше первоначальной, но покупателей это не останавливает.
При работе с партнерами, реализация билетов через кассы может сопровождаться необходимостью проведения рекламы мероприятия. Это индивидуально обговаривается с каждым партнёром, но несколько рекламных плакатов и брошюр на каждую торговую точку организатор обычно передаёт своим партнёрам.
В успешной рекламной кампании заинтересован и сам продавец билетов, и совместная работа в этой сфере может повысить эффективность в разы. Да и сами покупатели, бывает, в непосредственно самой точке интересуются мероприятиями, которые будут в ближайшее время проходить. Организаторы гастролей и вовсе могут предложить сотрудничество, одним из условий которого будет проведение рекламы в городе. Конечно, всё это возмещается организатором, но иметь в своём штате опытного маркетолога-рекламщика всё-таки стоит, ведь это позволит заниматься чуть ли не смежным бизнесом, зарабатывая дополнительный доход.
Торговля билетами выгодна тогда, когда имеется множество партнёров, проводящих самые разнообразные мероприятия – от детского кукольного театра до рок-концертов. Помимо них, следует сразу пытаться выходить на организаторов гастролей, одновременных шоу и каких-либо выступлений. По возможности, получать эксклюзив на реализацию билетов.
Хорошим каналом сбыта станут и театральные агентства, которые несут искусство в провинцию. Эти компании занимаются тем, что выкупают большую партию билетов, чтобы организовать тур из какого-либо провинциального городка в крупный город, где намечается премьера или грандиозное мероприятие. Здесь можно договориться о небольшой скидки, ведь агентство покупает немалую партию билетов (но называть их спекулянтами нельзя, потому что они и свою комиссию не слишком большой устанавливают, и ориентированы на тех клиентов, которые уже обратились).
Организации, являющиеся поставщиками билетов, регламентируют процесс продажи билетов, для того, чтобы исключить фактор спекулятивных цен. К процессу продажи билетов применяются следующие правила:
Начало предварительной продажи билетов на спектакли осуществляется за 3 месяца до даты проведения в соответствии с утвержденным графиком, который заранее размещается в кассовом зале.
Дата начала предварительной продажи билетов определяется по дате последнего представления в блоке показа.
В указанную в графике дату предварительная продажа билетов производится в кассах административного здания в период с 10:00 до 17:30. Билеты в первоочередном порядке отпускаются лицам, имеющим право внеочередной покупки, а затем всем остальным покупателям, желающим лично посетить спектакль, в порядке «живой» очереди.
В первый день предварительной продажи отпускается по 2 билета в одни руки на один из спектаклей (на одно представление из серии представлений каждого спектакля), предусмотренных графиком, при этом покупатель обязан предоставить кассиру общегражданский паспорт.
В первый день предварительной продажи во всех кассах театра осуществляется контроль за тем, чтобы один и тот же покупатель не совершил повторную покупку билетов на один и тот же спектакль.
Оставшиеся от предварительной продажи билеты после 17:30 поступают в свободную продажу во все кассы, на сайт Театра и официальным распространителям. В случае необходимости (из-за большого количества покупателей в очереди) время предварительной продажи билетов может быть продлено, о чем оповещается в соответствующих объявлениях.
Выбор средства для моделирования бизнес-процессов
Для проектирования информационной системы будет использована методология функционального моделирования. SADT – методология (Structured Analysis and Design Technique ) является распространенной в связи с тем, что ориентирована на комплексное представление структуры материальных, информационных, финансовых и управленческих потоков, отображение организационной структуры. В силу этого, SADT – это методология в большей степени нацеленная на реорганизацию всей системы управления, чем другие методологии функционального моделирования, основанные на использовании диаграмм потоков данных, главная цель которых проектирование информационных процессов [11].
Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций (операций, действий, работ – activity) бизнес-процесса.
Методология SADT реализована в следующих инструментальных средствах:
- Microsoft Visio.
- Bpwin process modeler.
- Ramus Educational.
- Dia [12].
Программный продукт Microsoft Visio — векторный графический редактор, который обеспечивает работы с диаграммами и блок-схемами для Windows. Редактор выпускается в трёх редакциях: Standard, Professional и Pro for Office 365 [4].
Аналогично с Adobe Reader, в стандартный набор программ MS Office входит только средство для просмотра и печати диаграмм Microsoft Visio Viewer. Полнофункциональная версия Microsoft Visio Professional для создания и редактирования монограмм и диаграмм в пакеты MS Office не входит и распространяется отдельно. Первоначально Visio разрабатывался и выпускался компанией Visio Corporation. Компания Microsoft приобрела компанию в 2000 году, тогда продукт назывался Visio 2000, был выполнен ребрендинг, и продукт был включен в состав Microsoft Office. Редактор поддерживает множество типов диаграмм, в которые входит IDEF0, DFD и другие методологии моделирования.
Редактор «Bpwin process modeler» — это программный продукт, разработанный компанией ltd. Logic Works. Он предназначен для поддержки процесса создания информационных систем. Относится к категории CASE средств верхнего уровня. BPwin является достаточно развитым средством моделирования, которое позволяет проводить анализ, документирование и улучшение бизнес процессов.
С его помощью можно моделировать действия в процессах, определять их порядок и необходимые ресурсы. Модели BPwin создают структуру, необходимую для понимания бизнес процессов, выявления управляющих событий и порядка взаимодействия элементов процесса между собой [1].
«Bpwin» поддерживает функциональное моделирование, моделирование потока работ и потока данных. Соответствующие диаграммы реализованы на основе стандартов IDEF0, IDEF3 и DFD. Функциональное моделирование дает возможность осуществлять систематизированный анализ бизнес процессов, обращая внимание на регулярно выполняемые задачи (функции).
Моделирование потока работ обеспечивает анализ логики выполнения процесса. Моделирование потока данных позволяет сконцентрировать внимание на обмене данными между различными задачами. Кроме того, что в BPwin создаются отдельные модели, также могут создаваться и смешанные модели [2].
Редактор «Ramus Educational» — кроссплатформенная система моделирования и анализа бизнес-процессов. В функционал редактора входят:
- разработка графических моделей бизнес-процессов (поддерживаются нотации IDEF0 и DFD);
- разработка систем классификации и кодирования (с привязкой к моделям процессов);
- формирование отчётности по моделям и системе классификации (в виде регламентов бизнес-процессов, должностных инструкций и т.п.).
Редактор «Dia» — это свободный кроссплатформенный редактор диаграмм, часть GNOME Office, но может быть установлен независимо. Он может быть использован для создания различных видов диаграмм: блок-схем алгоритмов программ, древовидных схем, статических структур UML, баз данных, диаграмм сущность-связь, радиоэлектронных элементов, потоковых диаграмм, сетевых диаграмм и других [9].
Для выбора инструментального средства необходимо выделить критерии, по которым выбор будет осуществляться:
- Поддержка нотаций IDEF0, DFD, IDEF3.
- Кроссплатформенность.
- Проверка нотации.
- Формирование отчетности.
Проанализируем инструментальные средства по выделенным критериям. Результат представлен в таблице 1.
Таблица 1
Анализ инструментальных средств
Источник: www.evkova.org
1.5. Пример описания и анализа предметной области
Рассмотрим на примере некоторые из приведенных этапов.
Цели, которые ставит перед бизнесом собственник, являются отправной точкой для формирования стратегии развития. В стратегии выбираются виды деятельности, рынки и формулируются те ключевые конкурентные преимущества, за счет которых компания должна добиться успеха. Описывая стратегию в упорядоченной форме, мы повышаем вероятность ее успешной реализации. Один из инструментов представления процесса реализации стратегии – сбалансированная система показателей ССП (Balanced ScoreCard, BSC), разработанная Робертом Капланом и Дейвидом Нортоном.
Сбалансированная система показателей – это система стратегического управления компанией на основе измерения и оценки ее эффективности по набору оптимально подобранных показателей, отражающих все аспекты деятельности организации, как финансовые, так и нефинансовые.
В результате применения рассматриваемого инструмента можно получить формализацию стратегии компании, выделить и зафиксировать в стратегической карте дерево целей компании, разработать показатели достижения этих целей. Показатели для наглядности могут быть размещены на диаграмме стратегической карты (рис. 16).
В левой части показаны перспективы: Финансы, Клиенты, Внутренние бизнес-процессы, Обучение и развитие.
Цели (элемент в виде эллипса) распределяются между этими категориями. В виде прямоугольников могут быть отображены некие показатели, которые показывают достижение цели. Для достижения главной цели может потребоваться решение задач, оценить которые в чисто финансовых показателях невозможно. В нашем примере на рост прибыли влияет не только сокращение издержек.
Наши стратеги решили, что не менее важно для достижения главной цели увеличивать количество клиентов, что в свою очередь требует удержания старых клиентов и привлечения новых. Показатели этой ветви целей не используются в системах финансового учета. Но для достижения нашей главной цели они столь же важны, как и финансовые.
Еще стоит отметить, что показатели принципиально могут быть двух типов: отсроченные и опережающие. Отсроченные показатели – это те, что показывают нам результаты выполнения стратегии по истечении заметного периода времени – нескольких месяцев, а возможно, и лет. Как пример, прибыль является именно отсроченным показателем. Но цели, влияющие на конечный результат, характеризуются, как правило, опережающими показателями – их нужно контролировать в динамике, чтобы быть уверенными в правильном движении по выбранному курсу. Примером такого показателя на нашей карте является «Процент недовольных клиентов», для него задается критическое значение, при превышении которого нужно немедленно поднимать тревогу.
Рис. 16. Пример диаграммы стратегической карты
Построить Систему Сбалансированных Показателей – и стратегической карты – означает выстроить такую систему целей и показателей различных типов и перспектив, которая обеспечивает достижение главной цели. При этом цели должны быть достижимыми и управляемыми (т. е. мы не можем, к примеру, задать «снижение курса евро» в качестве цели, поскольку не оказываем на это прямого влияния).
Имея четкую систему показателей, руководитель получает возможность контролировать процесс достижения целей. Разумеется, контроль над исполнением стратегического плана можно осуществлять только при условии наличия исполнителей.
Определив и формализовав стратегию, можно перейти к созданию модели бизнес-процессов компании. То есть определить ту деятельность, которую компания должна осуществлять для реализации стратегии и достижения поставленных целей.
Переходим ко второму этапу – созданию структуры предприятия.
На рис. 17 приведена организационная структура предприятия.
Далее осуществим построение модели бизнес-процессов.
Именно бизнес-процессы должны являться основой для построения системы управления и организационной структуры. То есть для конкретной задачи подбирается исполнитель с определенным образованием, возрастом, сертификатами и другими формальными требованиями. Возможен и часто применяется другой метод – имеется команда исполнителей, и при появлении какой-либо задачи подбирается наиболее подходящая кандидатура. Однако оптимизировать такую структуру намного сложнее.
Зная цели предприятия, выявленные на первом этапе, мы начинаем описывать конкретные действия, которые приводят к их достижению. Так, например, для достижения цели «своевременное выполнение проектных работ» требуется производить работы по каждому из проектов в соответствии с планом. Работы по каждому из проектов выполняются коллективом по более или менее стандартной методике, что позволяет выделить некоторую последовательность этапов, приводящих к конечному результату.
Рис. 17. Пример организационной структуры компании
Каждый из этапов может быть разбит на более простые действия – вплоть до элементарных процедур, выполняемых уже конкретными исполнителями. Детализация проводится до такого уровня, который представляется осмысленным – обычно она завершается там, где находится зона ответственности одного исполнителя.
Каждый шаг или процедура бизнес-процесса характеризуется потребляемыми ресурсами, временем исполнения и, соответственно, стоимостью. Введя все данные, мы получаем возможность рассчитать время и стоимость каждого бизнес-процесса и получить, в конечном итоге, плановую себестоимость нашей деятельности. Возможно, она нас не устроит, нам покажется, что это слишком сложно и дорого.
Далее рассмотрим оптимизацию на примере. На рис. 18 представлен типичный бизнес-процесс закупки товарно-материальных ценностей до оптимизации.
Бизнес-процесс начинается с получения заявки. Формируется заказ, направляется поставщику, тот выставляет счет на оплату. Счет с некоторой вероятностью утверждается руководителем и предоставляется бухгалтеру, после чего товар оказывается на складе (бизнес-процесс сокращен по сравнению с реальностью).
Если счет не утвержден, поставщику придется подумать о скидках, и цикл удовлетворения Руководителя проекта придется повторить. Произведем расчет стоимости и времени этого процесса. Для этого каждому использованному ресурсу назначается стоимость – например, размер оплаты за час работы сотрудника, а для каждой процедуры – время, затраченное этими сотрудниками. Помимо того в ходе работ счет потребуется распечатать, что потребует материальных затрат.
Возможно, потребуются телефонные переговоры, которые тоже стоят денег. Необходимо учесть, что каждый участник процесса занят еще и другими делами, поэтому задаем времена ожидания каждого действия. Заполнив свойства каждой процедуры, а также установив вероятность утверждения счета (90 %, например), выясняем, что средняя стоимость процедуры закупки составляет 10468 рублей, а среднее время выполнения – 136 часов.
Рис. 18. Бизнес-процесс закупки товарно-материальных ценностей до оптимизации
Далее допустим, что нас не устраивает средняя цена за этот бизнес-процесс. Начинаем искать, где мы могли бы сэкономить. В результате анализа обнаруживаем, что руководитель проекта тратит слишком много времени, подписывая счета на небольшие суммы, и принимаем решение, что счета до 50 000 рублей – а таких счетов у нас 80 % – можно оставить на усмотрение снабженца, который в процессе получения счета уже истребует необходимый размер скидки. В результате бизнес-процесс преобразуется к такому виду (рис. 19
На первый взгляд все очевидно – большая часть счетов пойдет мимо руководителя, и поскольку он является высокооплачиваемым специалистом, то средняя стоимость процедуры снизится. Тем же способом производя анализ, после экспериментов получаем точное значение – насколько снизится эта стоимость (табл. 6).
Стоимость процесса до и после оптимизации
Процедура до оптимизации
Источник: studfile.net
Императив предметной области при разработке информационных систем
В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами.
У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.
Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно?
Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.
Это напоминает упорное кодирование на ассемблере используя безусловно хорошие регламенты и инструменты, которые чуток облегчают наше суровое занятие, вместо того чтобы выйти на другой уровень – использовать новые языки и библиотеки, которые позволяют просто писать алгоритмы, не отвлекаясь на работу с устройствами и рутинными операциями.
Скорее всего, проблема кроется в том, что мы привыкли так делать. Существующая индустрия разработки, инструменты, УЯП сверхвысокого уровня, рынки обучения, найма и продвижения достались нам по наследству. А ещё есть страх машинерии, которая должна связывать все наши компоненты и поддерживать масштабирование, из-за которого мы порой забываем об императиве предметной области и превращаем себя в леммингов, занимающихся обслуживанием вспомогательных механизмов.
Всё это – тот монолит, который мы пытаемся масштабировать хотя бы на наше настоящее и надеемся, что будущее придёт и превратит ком грязи в карету. Но так не бывает! Мы сами должны это сделать. Мы и есть будущее!
Пожалуй, довольно пафоса. Давайте попробуем взглянуть на проблему с той стороны, с которой она должна быть рассмотрена, а не с той, с которой мы боимся на неё не смотреть.
Начинаем с описания предметной области
Для того, чтобы описать предметную область и иметь возможность формально обрабатывать это описание с помощью существующих технологий, нужен язык описания именно предметных областей. Проблема современных УЯП в том, что они слишком универсальны. Они обслуживают универсальные парадигмы, имеют алгоритмическую или другую семантику, не относящуюся прямо к семантике описания предметной области. Они прекрасно справляются со связыванием компонентов, что безусловно полезно, но слишком избыточно.
Как это не банально, но язык описания предметных областей должен обладать семантикой описания предметных областей. Только в этом случае можно будет действительно удобно формировать модель предметной области, не отвлекаясь на второстепенные конструкции. Фокусироваться на декомпозиции предметной области на взаимодействующие подобласти, а не продумывать механизмы связи между ними. Таких семантик может быть много, но для начала выберем одну из достаточно универсальных техник манипуляции предметными областями – Domain Driven Design (DDD) [1, 2].
Позже мы вернёмся к вопросу выбора семантики. Очевидно, выбор будет зависеть от конкретной предметной области, но точно не от инфраструктуры и архитектуры программного обеспечения (ПО) и не от наличия на рынке программистов на конкретном УЯП!
После выбора семантики описания предметной области можно определить синтаксис, который наилучшим образом её отражает. В итоге получится язык, который можно условно назвать Domain Driven Language (DDL). Далее будет приведён пример кода на этом языке. Но сначала давайте посмотрим, как это может работать.
На рисунке 1 приведена условная схема формирования информационной системы (ИС) на базе описания предметной области с использованием DDL.
Ключевым моментом является формирование из описания предметной области на DDL «чистой» семантики [3], которая на самом деле может являться набором стандартизированных JSON-документов и фрагментов кода на каком-либо УЯП, на основе которых, плюс заготовки для конкретной архитектуры, собирается ИС.
Условно названная «DevOps»-команда формирует компоненты архитектуры и инфраструктуры. Это сродни формированию библиотек компонент для различных сред работы приложения и в идеале может выполняться совершенного независимо от предметной области. Нужно лишь соблюдать соглашения о формате «чистой» семантики, не зная о её содержимом.
Можно видеть, что при такой схеме работы не столь важно в какую архитектурную и инфраструктурную среду мы помещаем автоматизацию предметной области. Вся эта машинерия, как и положено, находится под капотом. В результате может формироваться микросервисная архитектура с использованием заранее заготовленных компонентов и фреймворков для браузерного или мобильного UI.
А может – монолит настольного приложения в архитектуре махрового клиент-сервера. Да что угодно! И даже всё вместе! При одном и том же описании предметной области.
Некоторые новые возможности
Первое, что может спросить frontend-разработчик: «где же разработка пользовательского интерфейса»? Впрочем, это касается и остальных компонентов архитектуры: неужели пользователи будут довольствоваться автоматически генерируемыми неотёсанными версиями компонентов вроде интерфейса пользователя и других важных частей, которые вручную можно сделать гораздо более красивыми, удобными и оптимальными?
Конечно нет. В смысле действительно есть возможность на основе «чистой» семантики автоматически генерировать и интерфейс пользователя, и структуру базы данных, но никто не запрещает это делать вручную. Особенно в критических местах. Для этого случая можно дополнить схему разработки из рисунка 1 группой UI-дизайнеров, которые формируют важные элементы пользовательского интерфейса. Однако эти и другие группы желательно размещать под «чистой» семантикой.
Важно заметить, что на рисунке 1 изображена упрощённая схема, которая не отражает многих важных особенностей предлагаемого подхода в разработке ПО. Например, не показано, что может работать несколько DDD-команд, каждая из которых реализует свой ограниченный контекст предметной области. И не отображена возможность автоматизировать не только формирование ИС, но и взаимодействие этих команд, а также интеграцию этого взаимодействия в общем репозитории, баг-трекинге, вики и других инструментах организации разработки сложных программных систем.
Ещё одной особенностью подхода является возможное формирование расширений семантики DDL для учёта каких-то особенностей конкретной предметной области. Для этого можно использовать расширенную трактовку контрактного программирования [4].
Да много чего ещё может появиться интересного при таком подходе. В качестве ещё одного примера можно привести раннюю диагностику проблем в рамках семантики DDL, которая гораздо строже семантики любого УЯП. Это означает, что многие потенциальные проблемы, которые невозможно диагностировать при формировании кода на УЯП, будут подсвечиваться редактором при вводе описания модели предметной области на DDL, причём с учётом расширенных контрактов [4].
Рассмотрим простой пример
В качестве примера можно рассмотреть модель предметной области заказа в интернет-магазине – пример весьма канонический, знакомый и «любимый» многими. На рисунке 2 приведён скрин описания заказа на прототипе DDL в интегрированной среде разработки системы SIMODO [5, 6].
В приведённом примере значимые типы и атрибуты записываются на т.н. «общем языке» предметной области и могут автоматически формировать элементы UI и базы данных, что должно обеспечить пользователям знакомую среду работы.
Было бы крайне любопытно посмотреть на описание ваших предметных областей на этом языке, возможно, с использованием некоторых расширений (в виде модулей или дополнений в синтаксис языка), которые покажутся необходимыми. Это помогло бы в разработке языка. Можно предложить и свой синтаксис DDL.
Другие семантики предметных областей и предметно-ориентированные языки
Ранее было замечено, что семантика DDD – одна из многих возможных и для каких-то областей может быть совершенно неприменима. В качестве примера можно привести предметную область имитационного моделирования динамических систем, где модели естественным образом записываются в виде систем обыкновенных дифференциальных уравнений. Для этой предметной области естественным будет описание модели на специализированном языке дифференциальных уравнений.
На рисунке 3 приведен скрин с описанием модели на языке дифференциальных уравнений, а также фрагмент описания запуска процесса моделирования на языке, являющимся базовым для других предметно-ориентированных языков (ПОЯ).
Приведённый пример показывает, что можно использовать несколько языков, каждый из которых описывает свой участок предметной области. На рисунке 4 приведён фрагмент схемы из рисунка 1, который показывает более эффективное формирование модели предметной области, т.к. часть модели формируется специалистом собственноручно (безусловно, при этом может использоваться собственный ПОЯ, не обязательно только язык дифференциальных уравнений).
Таким образом, данный подход существенным образом привлекает специалиста предметной области к автоматизации своей работы, что ещё больше (по сравнению даже с Agile) увеличивает, как итеративность, так и качество процесса разработки.
Может показаться, что данный подход неоправданно сложный, т.к. необходимо поддерживать довольно большое количество ПОЯ. И не безосновательно. Однако почти любой новый подход бывает сложным. И на этот счёт разработан метод автоматизации разработки языков с использованием единой операционной семантики и расширений для интерпретаторов семантических дополнений [3].
Заключение
Предлагаемый подход обеспечивает кардинальную изоляцию предметной области от архитектуры и инфраструктуры разрабатываемой информационной системы, что должно позволить выбирать или менять компоненты архитектуры и инфраструктуры с минимальным влиянием на автоматизируемую предметную область. Также при использовании данного подхода, должно существенно сократиться не только время разработки, но и количество разработчиков на УЯП. А это значит, что разработка будет стоить значительно дешевле, чем при существующих подходах.
Одним из решений, предлагаемых для реализации данного подхода, является создание инструмента, автоматизирующего разработку языков для предметных областей, в том числе для DDD, как предметной области автоматизации предметных областей. Такой инструмент в настоящее время разрабатывается на кафедре ИУ6 МГТУ им. Н.Э. Баумана.
Библиографические ссылки
Часть материалов и статей ещё не обработана или являются платными.
- Domain Driven Design
- DDD
- семантика
- предметно-ориентированный язык
- микросервисы
Источник: habr.com
