Описание предметной области что это

Описание предметной области и определение цели проектирования

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

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

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

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

Желательно описать алгоритмы выполнения тех или иных операций исполнителей конкретных видов работ или действий.

Здесь же должна быть сформулирована цель разработки учебной базы данных, например «Автоматизация профессиональной деятельности в конкретной предметной области» (или другая).

Анализ предметной области и инфологическое проектирование

В разделе «Функциональная модель предметной области» должны быть приведены результаты функционального моделирования предметной области учебной базы данных, выполненного в среде BPwin. Словесные описания особенностей функционирования предметной области должны сопровождаться изображениями контекстной диаграммы предметной области, диаграмм декомпозиции, иерархической схемы функций (Node Tree-диаграммы BPwin) (рис. 4-6), а также сводными таблицами (табл. 1 и 2) описаний работ (функций) и стрелок (данных).

Р ис. 4. Пример контекстной диаграммы предметной области «Библиотека»

Рис. 5. Пример диаграммы декомпозиции предметной области «Библиотека»

Рис. 6. Пример иерархической диаграммы функций предметной области «Библиотека»

Номер работы

Описание работы

Под работой библиотеки имеются в виду технологические аспекты ее функционирования

Комплектование библиотеки и хранение новых книг

Комплектование библиотеки предполагает приобретение новых книг, их хранение и списание

Справочно-библиографическое обслуживание предполагает занесение сведений о книгах в каталог и поиск книг в каталоге

Абонементное обслуживание

Абонементное обслуживание, в том числе:

1) запись на абонемент

2) поиск книг в каталоге

3) оформление заявки в хранилище

5) прием возвращенных книг

Комплектование библиотеки предполагает приобретение новых книг и списание пришедших в негодность. При комплектовании каждому экземпляру книги присваивается инвентарный номер

Экземпляры книг хранятся в хранилище и выдаются по заявкам абонентов во временное пользование

Занесение в каталог

Вновь приобретенные книги регистрируются в каталоге

По запросу абонента осуществляется поиск информации о книге в каталоге

Запись на абонемент

Посетители библиотеки могут быть записаны в качестве ее абонентов

Поиск сведений о книге выполняется по заявке абонента

Затребованные книги при наличии их в хранилище могут быть выданы

При наличии свободного экземпляра книги в хранилище оформляется заявка на затребованную книгу

Выданные книги подлежат возврату и размещению их в хранилище

Имя стрелки

Описание стрелки

Абоненты — это зарегистрированные клиенты библиотеки. После регистрации они приобретают права законных пользователей

Бюджет регламентирует все виды работ в библиотеке

Возвращенные на абонемент книги размещаются в хранилище

Выданные книги — это один из вариантов книг на выходе и один из вариантов поступления книг

Перед оформлением заявки выполняется запрос на поиск информации о книге в каталоге

Статус зарегистрированной приобретает книга после ее занесения в каталог. После регистрации в каталоге зарегистрированная книга поступает на хранение

При наличии свободного экземпляра по заявке затребованная книга поступает на абонемент

При наличии свободного экземпляра книги оформляется заявка на ее получение во временное пользование

Книги на входе

Источники книг на входе библиотеки:

1) новые поступления

2) возвращенные книги

Книги на выходе

Книги на выходе‑это:

1) зарегистрированные, но не востребованные книги

2) выданные книги

3) списанные книги

Новые книги — это один из вариантов поступления книг в библиотеку

Библиотеку могут посещать клиенты, не являющиеся ее абонентами

Правила пользования распространяются только на справочно-библиографическое и абонементное обслуживание

Книги, пришедшие в негодность, подлежат списанию. Это один из вариантов книг на выходе

Справка — это результат справочно-библиографического поиска по запросу абонента

После поступления новой книге присваивается инвентарный номер и она приобретает статус учтенной книги. Учтенная книга поступает на хранение

Книги, поступившие на хранение либо после присваивания им инвентарного номера, либо после их регистрации в каталоге

В разделе «Информационная модель предметной области» должны быть приведены результаты разработки информационной модели предметной области в терминах модели «сущность-связь», выполненной в среде ERwin (т.н. Logical Model) [10] (рис. 7).

В разделе «Спецификации сущностей» следует для каждой сущности указать:

Результаты удобно свести в таблицу типа приведенной ниже (табл. 3). При построении таблицы следует воспользоваться возможностями ERwin для формирования отчетов (по команде Tasks/Generate Reports).

Имя сущности

Описание сущности

История выдач и возврата книг. Содержит сведения о том, кому, кем, что и когда было выдано или возвращено

Содержит информацию об абонентах библиотеки

Содержит информацию о книге, зарегистрированной в каталоге

Содержит информацию о сотрудниках библиотеки

Сотрудник, являющийся абонентом библиотеки

Студент, являющийся абонентом библиотеки

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

В разделе «Спецификации атрибутов» для каждого атрибута указать:

Результаты удобно свести в таблицу типа приведенной ниже (табл. 4). При построении таблицы следует воспользоваться возможностями ERwin для формирования отчетов (по команде Tasks/Generate Reports).

Рис. 7. Пример информационной модели предметной области «Библиотека»

Спецификации атрибутов сущностей

Имя сущности

Имя атрибута

Описание атрибута

Первичный ключ

Внешний ключ

Инвентарный номер книги на абонементе — компонент первичного ключа и ключ связи с сущностью «Хранимая книга»

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

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

И вот как здорово, Олега приглашают поработать в проекте для зарубежной фармакологической Компании N.
Компания N занимается клиническими исследованиями и производством лекарств.

Олегу нужно спроектировать систему для хранения и передачи результатов клинических исследований внутри компании N.

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

Первым делом Олег отправляется изучать техническое задание.
И не понимает ни слова.
Более того, Олегу говорят, что через неделю он летит в командировку в лабораторию к клиенту, собирать данные о пользователях. Но Олег не понимает, что собирать, потому что не понимает совсем ничего.

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

Пока Олег прокрастинирует и самобичуется, попробуем разобраться, почему так вышло.

Дело в том, что сложно понять дизайн-задачу, если не понимаешь, о чем проект.

Привычные и понятные проекты, вроде тех, с которыми имел дело Олег, не требуют много времени на погружение. В таких проектах разрабатывается то, с чем мы сталкиваемся достаточно часто: интернет-магазины, посадочные страницы, календари и пр.

Но бывают исключения — проекты со сложной предметной областью.

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

Предметная область — это специфическая группа знаний.

Помните, в школе у нас были разные предметы: химия, физика, биология?

Это — разные предметные области и учителя давали нам базовое понимание каждой из них.

Для UX-дизайнера предметная область — это контекст, в котором существует (или будет существовать) система и пользовательский интерфейс.

Компоненты предметной области

Для удобства можно разделить предметную область на три компонента:

• специфичные термины и язык людей, которые живут/работают в предметной области,
• важные объекты, существенные единицы предметной области,
• то, как эти единицы вязаны и взаимодействуют.

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

Чем глубже вы понимаете контекст проекта, тем эффективнее вы работаете на начальных этапах.

Как разобраться в предметной области

В знании предметной области я условно выделяю 4 этапа (или, если угодно, состояния поектировщика):

Сейчас Олег находится в состоянии “Я ничего не знаю”.
На то, чтобы максимально преисполниться и достичь состояния “Я эксперт” у Олега могут уйти годы. Как и у любого из нас.
Поэтому последний этап мы опустим и поговорим о том, как достичь состояний “Я знаю, чего я не знаю” и “Я кое-что знаю”.

И первый шаг на пути к просветлению — домашнее чтение.

Шаг 1: домашнее чтение

Итак, Олег берет себя в руки и решает перебраться из состояния «Я ничего не знаю» в «Я знаю, чего я не знаю». Он начинает читать.

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

Олег остается один на один с тонной новой информации и разрозненных терминов.
Яснее не стало.

Олег предполагал, что путь будет прост.

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

Как же из этой тонны информации выбрать то, что важно знать для проекта?

Вам нужно знать ровно столько, сколько вам нужно знать.

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

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

Какие вопросы о предметной области нужно сформулировать

Как мы уже обсудили, предметная область состоит из 3 компонентов: словарь, сущности и связи между ними.

Для каждого компонента можно сформулировать вопросы и попытаться на них ответить (см. схему ниже).

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

Артефакт — описание продукта с определённой точки зрения по заданному формату. Он помогает договориться всем участникам процесса, но его не увидит конечный пользователь.

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

В случае изучения предметной области помогают 2 артефакта:

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

Именно этими артефактами решает заняться Олег.
Он создает таблицу — словарь, куда вносит непонятные слова и предполагает их смысл.

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

На основе своих артефактов Олег может составить вопросы.

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

С домашним чтением покончено, у Олега куча вопросов.
Он знает, чего он не знает.

Что же с этими вопросами делать дальше? Самое время обратиться к экспертам.

Шаг 2: Общение с экспертами

Немного разобравшись с базовыми понятиями и сформулировав вопросы, Олег отправляется выяснять тонкие детали к экспертам.

Почему нельзя сразу начать с экспертов, не тратя время на домашнее чтение?
Эксперты — занятые люди. У них полно своих дел и работы.
Лучше заранее разобраться в базовых вещах и сформулировать конкретные вопросы. Это позволит предметно и по существу общаться с экспертами, не тратя их время на объяснение основ.

Кто такие эксперты и где их взять?

Эксперты — люди, которые разбираются в предметной области и/или в ней работают. Они уже прошли минимум 2 этапа познания и находятся в состоянии “Я кое-что знаю” или “Я эксперт”.

Ближайшими в зоне досягаемости экспертами могут выступать коллеги на проекте.
Например, менеджер/руководитель проекта или бизнес-аналитик, которые уже давно варятся в этой кухне.
Если до вас на проекте работали дизайнеры, они могли немного разобраться и оставить полезные документы.
Часть сформулированных вопросов и гипотез можно обсудить с коллегами.

Безусловно, экспертами являются лица, заинтересованные в реализации проекта:

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

Для эффективного общения с заказчиком/пользователями можно использовать интервью и наблюдение.

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

Артефакты обновлены.
Словарь содержит верное объяснение терминов, в нем много деталей о разных понятиях, присущих компании N.

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

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

Безусловно, со временем Олег еще лучше разберется в предметной области своего проекта и его артефакты дополнятся деталями.

Вывод

Попадая на проект со сложной (даже немножко) предметной областью, будьте как Олег.
Исследуйте предметную область в два простых шага:

1. Домашнее чтение. Это позволит сформировать общее представление о терминах, ролях и процессах; сформулировать гипотезы и вопросы к экспертам
2. Общение с экспертами. Это позволит прояснить детали, проверить гипотезы, и дополнить артефакты: словарь терминов и модель связей сущностей.

Немного полезных советов:

• Будьте проактивны
• Помните: вы не эксперт
• Сфокусируйтесь на компонентах предметной области (словарь, сущности, связи)
• Не бойтесь задавать вопросы
• Сначала пообщайтесь с коллегами, затем с экспертами
• Пишите заметки и проверяйте их
• Документируйте

Если статья показалась интересной — дайте знать аплодисментами ��

Больше о проектировании интерфейсов и мемы по средам можно найти в телеграм-канале Поясни за UX

Описание предметной области

2012, June 13
Станислав

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

Роберт Т. Киосаки

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

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

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

Описание предметной области — Примеры

Примеры неудачных определений

Главная ошибка — давать определения неизвестных слов при помощи других неизвестных слов или однокоренных слов.

Итератор — это чистая абстракция, то есть все, что ведет себя как итератор и есть итератор.

Существование — деятельность организма для удовлетворения витальных потребностей.

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

Примеры правильных определений

Технико-экономическое обоснование (ТЭО) — документ, который доказывает, что проект технически возможен и экономически выгоден. ТЭО — это документ-идея.

Бизнес-план — документ, который дает подробную информацию о том, кто собирается реализовать бизнес-проект, каким образом, в какие сроки и на каком рынке. Бизнес-план — это документ-реализация.

Пример правильных определений без создания специального раздела

Прежде чем начать предлагаю разобраться в понятиях «жизнь» и «существование».

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

Жизнь — деятельность человека как личности. Не учитывая сложностей социальной философии, предположу что, жизнь — это развитие, созидание, свобода действий.

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

Описание предметной области — Пример с диаграммой

Представленное ниже описание предметной области используется при моделировании бизнес-процессов, а также при разработке программного обеспеченья. К сожалению, здесь я не буду объяснять правила построения таких диаграмм (подробнее об этой графической нотации см. UML).

Для лучшего понимания предметной области диаграмма дополняется описанием.

Заказчик

Атрибут	Тип	Описание
Название	Строка (30)*	Сокращенное наименование заказчика
Юр. название	Строка (70)*	Юридическое наименование заказчика
Контакты	Текст*	Контактные лица и контактная информация
Дополнительно	Текст	Дополнительная информация о заказчике

Продукт

Экземпляр

Один и тот же продукт может иметь несколько копий и размещаться на разных площадках (на площадке разработчика, на площадке тестировщика, на демонстрационной площадке и т.д.). Каждая такая копия продукта называется Экземпляром.

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

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

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

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

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

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

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

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

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

Как это не банально, но язык описания предметных областей должен обладать семантикой описания предметных областей. Только в этом случае можно будет действительно удобно формировать модель предметной области, не отвлекаясь на второстепенные конструкции. Фокусироваться на декомпозиции предметной области на взаимодействующие подобласти, а не продумывать механизмы связи между ними. Таких семантик может быть много, но для начала выберем одну из достаточно универсальных техник манипуляции предметными областями – Domain Driven Design (DDD) [1, 2].

Позже мы вернёмся к вопросу выбора семантики. Очевидно, выбор будет зависеть от конкретной предметной области, но точно не от инфраструктуры и архитектуры программного обеспечения (ПО) и не от наличия на рынке программистов на конкретном УЯП!

После выбора семантики описания предметной области можно определить синтаксис, который наилучшим образом её отражает. В итоге получится язык, который можно условно назвать Domain Driven Language (DDL). Далее будет приведён пример кода на этом языке. Но сначала давайте посмотрим, как это может работать.

На рисунке 1 приведена условная схема формирования информационной системы (ИС) на базе описания предметной области с использованием DDL.

Рисунок 1. Схема формирования информационной системы из описания предметной области с использованием DDL

Ключевым моментом является формирование из описания предметной области на DDL «чистой» семантики [3], которая на самом деле может являться набором стандартизированных JSON-документов и фрагментов кода на каком-либо УЯП, на основе которых, плюс заготовки для конкретной архитектуры, собирается ИС.

Условно названная «DevOps»-команда формирует компоненты архитектуры и инфраструктуры. Это сродни формированию библиотек компонент для различных сред работы приложения и в идеале может выполняться совершенного независимо от предметной области. Нужно лишь соблюдать соглашения о формате «чистой» семантики, не зная о её содержимом.

Можно видеть, что при такой схеме работы не столь важно в какую архитектурную и инфраструктурную среду мы помещаем автоматизацию предметной области. Вся эта машинерия, как и положено, находится под капотом. В результате может формироваться микросервисная архитектура с использованием заранее заготовленных компонентов и фреймворков для браузерного или мобильного UI. А может – монолит настольного приложения в архитектуре махрового клиент-сервера. Да что угодно! И даже всё вместе! При одном и том же описании предметной области.

Некоторые новые возможности

Первое, что может спросить frontend-разработчик: «где же разработка пользовательского интерфейса»? Впрочем, это касается и остальных компонентов архитектуры: неужели пользователи будут довольствоваться автоматически генерируемыми неотёсанными версиями компонентов вроде интерфейса пользователя и других важных частей, которые вручную можно сделать гораздо более красивыми, удобными и оптимальными?

Конечно нет. В смысле действительно есть возможность на основе «чистой» семантики автоматически генерировать и интерфейс пользователя, и структуру базы данных, но никто не запрещает это делать вручную. Особенно в критических местах. Для этого случая можно дополнить схему разработки из рисунка 1 группой UI-дизайнеров, которые формируют важные элементы пользовательского интерфейса. Однако эти и другие группы желательно размещать под «чистой» семантикой.

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

Ещё одной особенностью подхода является возможное формирование расширений семантики DDL для учёта каких-то особенностей конкретной предметной области. Для этого можно использовать расширенную трактовку контрактного программирования [4].

Да много чего ещё может появиться интересного при таком подходе. В качестве ещё одного примера можно привести раннюю диагностику проблем в рамках семантики DDL, которая гораздо строже семантики любого УЯП. Это означает, что многие потенциальные проблемы, которые невозможно диагностировать при формировании кода на УЯП, будут подсвечиваться редактором при вводе описания модели предметной области на DDL, причём с учётом расширенных контрактов [4].

Рассмотрим простой пример

В качестве примера можно рассмотреть модель предметной области заказа в интернет-магазине – пример весьма канонический, знакомый и «любимый» многими. На рисунке 2 приведён скрин описания заказа на прототипе DDL в интегрированной среде разработки системы SIMODO [5, 6].

Рисунок 2. Пример описания агрегата «Заказ» на прототипе DDL в интегрированной среде разработки системы SIMODO

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

Было бы крайне любопытно посмотреть на описание ваших предметных областей на этом языке, возможно, с использованием некоторых расширений (в виде модулей или дополнений в синтаксис языка), которые покажутся необходимыми. Это помогло бы в разработке языка. Можно предложить и свой синтаксис DDL.

Другие семантики предметных областей и предметно-ориентированные языки

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

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

Рисунок3. Пример описания модели динамического объекта и запуска моделирования в интегрированной среде разработки системы SIMODO

Приведённый пример показывает, что можно использовать несколько языков, каждый из которых описывает свой участок предметной области. На рисунке 4 приведён фрагмент схемы из рисунка 1, который показывает более эффективное формирование модели предметной области, т.к. часть модели формируется специалистом собственноручно (безусловно, при этом может использоваться собственный ПОЯ, не обязательно только язык дифференциальных уравнений).

Рисунок 4. Применение ПОЯ при формировании модели предметной области

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

Может показаться, что данный подход неоправданно сложный, т.к. необходимо поддерживать довольно большое количество ПОЯ. И не безосновательно. Однако почти любой новый подход бывает сложным. И на этот счёт разработан метод автоматизации разработки языков с использованием единой операционной семантики и расширений для интерпретаторов семантических дополнений [3].

Заключение

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

Одним из решений, предлагаемых для реализации данного подхода, является создание инструмента, автоматизирующего разработку языков для предметных областей, в том числе для DDD, как предметной области автоматизации предметных областей. Такой инструмент в настоящее время разрабатывается на кафедре ИУ6 МГТУ им. Н.Э. Баумана.

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

Эванс Э. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2011. – 448 с.

Вернон В. Реализация методов предметно-ориентированного проектирования. : Пер. с англ. – СПб. Ж ООО «Диалектика». 2019. – 688 с.

Иванова Г.С., Фетисов М.В., Малкина Т.А., Ралдугина А.В. Унификация работы с предметно-ориентированными языками и открытая программная архитектура в адаптивной системе имитационного моделирования // Динамика сложных систем. 2021. T. 15. № 3. С. 36−47. DOI: 10.18127/j19997493-202103-03

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).

Иванова Г.С., Жильцов А.И., Фетисов М.В., Чулин Н.А., Юдин А.Е. Адаптивная система моделирования. – Автоматизация. Современные технологии, номер 11 за 2020 год, стр. 500.