Что такое предметная область в программировании

Предметная область (Object domain)

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

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

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

Что такое предметная область в программировании

О разработке программного обеспечения. Модельный взгляд

© 2018
Легалов А.И.

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

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

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

Между системами программирования и методами разработки ПО нет четкой грани. Существует их взаимное влияние друг на друга вне зависимости от используемых подходов и технических средств. Совместное использование заключается в том, что методы проектирования применяются для «ручного» перехода от исходных моделей к программам, а системы программирования обеспечивают непосредственное написание программ и их автоматический перевод в язык конкретного исполнителя. Например, объектно-ориентированная методология (ООМ) предлагает унифицированный процесс проектирования, инструментальная поддержка которого обеспечивает непосредственное построение каркасов программных приложений. Совместное использование методик проектирования и систем программирования осуществляется также при других методах разработки программного обеспечения.

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

• Корректность (правильность). Программа обеспечивает правильную обработку на правильных данных.
• Устойчивость. Программа «элегантно» завершает обработку ошибок.
• Расширяемость. Программа может легко адаптироваться к изменяющимся требованиям.
• Многократность использования. Программа может использоваться и в других системах, а не только в той, для которой было создана.
• Совместимость. Программа может легко использоваться с другим программным обеспечением.
• Эффективность. Обеспечивается эффективное использование времени, компьютерной памяти, дискового пространства и т.д.
• Переносимость. Разработанное программное обеспечение можно легко перенести на другие аппаратные и программные средства.
• Верификация. Простота проверки, легкость разработки тестов при обнаружении ошибок, легкость обнаружения мест, где программа потерпела неудачу, и т.д.
• Поддержка целостности. Программа защищает себя от неправильного обращения и неправильного употребления.
• Легкость использования. Не возникает проблем для пользователя в эксплуатации программы, а для будущих программистов в ее дальнейшем сопровождении и развитии.

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

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

Факторы, определяющие процесс разработки программного обеспечения

Среди множества факторов, от которых зависит процесс разработки программного обеспечения, можно выделить:

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

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

Цель процесса разработки – создание программы, обеспечивающей решение поставленной задачи некоторым исполнителем и удовлетворяющей при этом требуемым критериям качества. Решаемая задача описывается совокупностью формальных и эмпирических (неформальных) моделей, определяющих как протекающие в программе процессы, так и используемые при этом данные.

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

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

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

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

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

Рисунок 1 – Процесс разработки программного обеспечения как отображение модели задачи на модель исполнителя

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

Рисунок 2 – Влияние сложности задачи на процесс преобразования исходных моделей в модели исполнителя

Императив предметной области при разработке информационных систем

В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами. У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.

Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.

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

Скорее всего, проблема кроется в том, что мы привыкли так делать. Существующая индустрия разработки, инструменты, УЯП сверхвысокого уровня, рынки обучения, найма и продвижения достались нам по наследству. А ещё есть страх машинерии, которая должна связывать все наши компоненты и поддерживать масштабирование, из-за которого мы порой забываем об императиве предметной области и превращаем себя в леммингов, занимающихся обслуживанием вспомогательных механизмов.

Всё это – тот монолит, который мы пытаемся масштабировать хотя бы на наше настоящее и надеемся, что будущее придёт и превратит ком грязи в карету. Но так не бывает! Мы сами должны это сделать. Мы и есть будущее!

Пожалуй, довольно пафоса. Давайте попробуем взглянуть на проблему с той стороны, с которой она должна быть рассмотрена, а не с той, с которой мы боимся на неё не смотреть.

Начинаем с описания предметной области

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

Как это не банально, но язык описания предметных областей должен обладать семантикой описания предметных областей. Только в этом случае можно будет действительно удобно формировать модель предметной области, не отвлекаясь на второстепенные конструкции. Фокусироваться на декомпозиции предметной области на взаимодействующие подобласти, а не продумывать механизмы связи между ними. Таких семантик может быть много, но для начала выберем одну из достаточно универсальных техник манипуляции предметными областями – 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 МГТУ им. Н.Э. Баумана.

Библиографические ссылки

1. Эванс Э. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 с.
2. Вернон В. Реализация методов предметно-ориентированного проектирования. : Пер. с англ. – СПб. Ж ООО «Диалектика». 2019. – 688 с.
3. Иванова Г.С., Фетисов М.В., Малкина Т.А., Ралдугина А.В. Унификация работы с предметно-ориентированными языками и открытая программная архитектура в адаптивной системе имитационного моделирования // Динамика сложных систем. 2021. T. 15. № 3. С. 36−47. DOI: 10.18127/j19997493-202103-03
4. Ivanova G.S., Fetisov M.V. The concept of contract management in the base language of the adaptive modeling system. [Электронный ресурс]. URL: https://summa.stu.lipetsk.ru/assets/Final_programm.pdf (дата обращения: 05.12.2021).
5. Иванова Г.С., Жильцов А.И., Фетисов М.В., Чулин Н.А., Юдин А.Е. Адаптивная система моделирования. – Автоматизация. Современные технологии, номер 11 за 2020 год, стр. 500.
6. SIMODO/stars в репозитории МГТУ им. Н.Э. Баумана. [Электронный ресурс]. URL: https://bmstu.codes/lsx/simodo/stars (дата обращения: 05.12.2021).

Часть материалов и статей ещё не обработана или являются платными.

• Domain Driven Design
• DDD
• семантика
• предметно-ориентированный язык
• микросервисы

Что такое предметная область в программировании

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

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

Ведь софт может быть: игры, аудиоплееры, видеоплееры и др. — софт, который не используется для осуществления профессиональной деятельности — Для такого софта тоже применяется и рассматривается понятие предметной области??

DrStrangeLove

Посмотреть профиль

Найти ещё сообщения от DrStrangeLove